Internet DRAFT - draft-lindgren-icnrg-lwm2m4icn
draft-lindgren-icnrg-lwm2m4icn
ICN Research Group A. Lindgren
Internet-Draft RISE SICS
Intended status: Experimental B. Ahlgren
Expires: May 18, 2018 SICS
November 14, 2017
OMA Lightweight M2M for Management of Information Centric Networks
draft-lindgren-icnrg-lwm2m4icn-00
Abstract
The Internet-of-things (IoT) supports many applications and services
where collection and distribution of data from and to devices is
central, fitting the named data communication model of information-
centric networking (ICN) quite well. Many applications and use cases
of the Internet of Things (IoT) imply information centric usage
patterns. The IoT differs from many typical information centric
application because of the dynamic nature of IoT devices and the
large number of such devices. This creates a requirement for easy
deployability in new locations without the need for complex setup or
configuration of the devices. This draft provides a study of how the
OMA Lightweight M2M (LWM2M) protocol for IoT device management can
potentially be used for configuration and management of ICN
parameters in an IoT network. We will address some of the tradeoffs
that need to be considered and give an initial example of how key
LWM2M functionality can be mapped to the ICN/IoT scenario.
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 18, 2018.
Lindgren & Ahlgren Expires May 18, 2018 [Page 1]
Internet-Draft LWM2M for ICN Management November 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 and Background . . . . . . . . . . . . . . . . . 2
2. CCN Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Naming of IoT data over CCN . . . . . . . . . . . . . . . 4
3. Lightweight M2M Overview . . . . . . . . . . . . . . . . . . 4
3.1. LWM2M Object Model . . . . . . . . . . . . . . . . . . . 5
3.2. LWM2M Functionality . . . . . . . . . . . . . . . . . . . 7
3.2.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Device registration and disconnection . . . . . . . . 7
3.2.3. Object access by server . . . . . . . . . . . . . . . 7
3.2.4. Observing objects . . . . . . . . . . . . . . . . . . 8
4. Using LWM2M Functionality for ICN Setup . . . . . . . . . . . 8
4.1. Configuration of CCN properties for IoT devices . . . . . 8
4.2. Configuration of CCN routers . . . . . . . . . . . . . . 10
4.3. LWM2M as an ICN directory service . . . . . . . . . . . . 10
4.4. Running LWM2M over ICN . . . . . . . . . . . . . . . . . 11
5. Future Work and Realisation Plans . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction and Background
Many applications and services of the Internet-of-things (IoT)
involve collection and distribution of data from and to devices and
users. This communication need often fits the named data
communication model of information-centric networking (ICN)
[Ahl-icn-survey-commag] where data consumers are decoupled from data
publishers. The ICN paradigm has been shown to efficiently meet
current usage demands of computer networks, where users consume
content from the network instead of communicating with specific
Lindgren & Ahlgren Expires May 18, 2018 [Page 2]
Internet-Draft LWM2M for ICN Management November 2017
hosts. The applications and usage of the Internet of Things (IoT)
often imply information centric usage patterns, where users or
devices consume IoT generated content from the network instead of
communicating with specific hosts or devices.
However, while the IoT shares many characteristics with typical
information centric applications, it differs because of the high
heterogeneity of connected devices (including sensors and actuators),
the potentially very high rate of new information being generated,
and the heterogeneity in requirements from applications regarding
information retrieval and dynamic actuation. Furthermore, the
dynamic nature of IoT devices and the large number of such devices,
results in a requirement for easy deployability in new locations
without the need for complex setup or configuration of the devices.
This includes both network-level aspects such as naming and routing
parameters as well as security material such as certificates or
encryption keys.
Previous work have addressed some of the technical challenges and
tradeoffs involved in mapping IoT functionality onto the ICN
paradigm. The ephemeral data aspect of IoT and the challenges of
convenient deployment and configuration of lightweight devices in an
ICN are however yet to be evaluated and provide us the motivation for
this case study of the possibility to utilise LWM2M to enable the use
of ICN in IoT networks. This draft provides a pre-study of how an
Advanced Connectivity Platform using the OMA Lightweight M2M (LWM2M)
protocol for IoT device management can potentially be used for
configuration and management of ICN parameters in an IoT network. We
will address some of the tradeoffs that need to be considered and
give an initial example of how LWM2M functionality can be mapped to
the ICN/IoT scenario. This information is intended to be used as a
basis for further discussion on architectural design for ICN
implementations such as CCNx and CCN-lite.
2. CCN Overview
Over the past years, several network architectures embodying the
information centric networking paradigm have been defined, such as
NetInf, NDN and CCN. In this examination of the possible use of
LWM2M for IoT over ICN, we have chosen to focus on the content
centric networking (CCN) architecture. This decision was motivated
by its popularity in the research community. Although our
discussions focus on the CCN architecture, many conclusions and
designs can be generalized to other ICN architectures with minor
modifications.
Lindgren & Ahlgren Expires May 18, 2018 [Page 3]
Internet-Draft LWM2M for ICN Management November 2017
2.1. Naming of IoT data over CCN
IoT encompasses varied topologies, network architectures, content
models and applications. To understand how the use of CCN differs in
an IoT setting as compared to an Internet scale network, some major
features of IoT networks that influence CCN operation have been
previously identified, including some of the tradeoffs and design
choices to be made for such situations
[draft-lindgren-icnrg-designchoices]
[draft-zhang-icnrg-iot-requirements-00]. Most importantly, we
consider how to name data in a content centric IoT network. We
assume that most sensors generate periodic data in a time series
manner where each new CO generated is a more recent value of a
reading than the previous one. Content from sensors are modelled as
streams of immutable objects being published with increasing sequence
numbers in their names, similar to video chunks in a live video
stream. A new CO is given a CCN name on the format /CCN-
prefix/datastream/sequence. When a new CO from the content stream of
a producer is published (made available) it is requested by consumers
interested in it. These requests are highly correlated in the time
window after their publishing and before a newer one is made
available. Requests for older data are either non-existent or
infrequent in time series content streams. This model is very
different from those used for most traffic in Internet scale networks
(apart from live TV) where requests for a certain content object
could be spread over long time durations.
This naming convention does however create two large challenges.
Knowing the CCN-prefix to be used in the name of data is difficult
both for the producer of data unless this can be statically
configured upon deployment of the device as well as for applications
and other data consumers that need to know which name to request.
Similarly, if an application wants to retrieve the latest CO in a
data stream, it needs to know the most recent sequence number. It
has been shown that it is possible to scan the sequence number space
to find the most recent object, but this scan should start at a
sequence number that was created relatively recently to avoid large
overhead. As we will see in later sections, both these issues can be
addressed through the use of LWM2M.
3. Lightweight M2M Overview
The Open Mobile Alliance (OMA) has defined a Device Management
protocol that is currently in use in many cellular networks by
operators and enterprises worldwide to manage the devices in those
networks. This works very well for remote management and
configuration of more powerful devices such as mobile phones. There
is however a need for a more lightweight device management protocol
Lindgren & Ahlgren Expires May 18, 2018 [Page 4]
Internet-Draft LWM2M for ICN Management November 2017
to manage the upcoming plethora of M2M and IoT devices that are
expected to soon populate most mobile networks.
The OMA Lightweight M2M (LWM2M) protocol [lwm2m] is designed by the
Open Mobile Alliance (OMA) for M2M/IoT device management. The OMA
specification defines the application layer communication protocol
between a LWM2M Server and Client (the IoT device). It includes
device management and service enablement for resource constrained IoT
devices. The idea is thus to use a light and compact protocol as
well as an efficient resource data model. The protocol is designed
to provide device management functionality over sensor or cellular
networks and transfer service data from the network to devices. Many
previous M2M systems (and associated management protocols) have been
highly siloed without interoperability. LWM2M is based purely on
open IETF standards such as DTLS for security, and the CoAP protocol
which is widely available in IoT platforms. It should also be
extensible to meet the requirements of most applications through its
object model, which can be used both for management as well as for
application data.
3.1. LWM2M Object Model
Each LWM2M client (IoT device) has one or more Object Instances.
Each such Object is a collection of Resources which are atomic pieces
of information that can be read, written, and/or executed. Ssuch
actions on the resources are mapped to RESTful CoAP calls through
READ, PUT, POST, respectively. Resources can have multiple
instances, for example, multiple instances of Access control list
(ACL) objects to control access to different other objects by the
server. Objects and Resources are identified by 16-bit integers,
Instances by 8-bit integers, and are named and accessed by simple
URIs such as Object ID/Object Instance/Resource ID. The first seven
Object IDs are defined as standard device management objects as
listed in Figure 1. For example, Figure 2 shows the definition of
the Location object, so the longitude of a device is represented by
the URI /6/0/1 (6 is the location object, 0 is the instance ID since
there is only a single instance, and 1 is the resource id for
longitude in the location object).
Lindgren & Ahlgren Expires May 18, 2018 [Page 5]
Internet-Draft LWM2M for ICN Management November 2017
+--------------+-----------+--------------------+
| Object Name | Object ID | Multiple instances |
|--------------+-----------+--------------------|
|LWM2M Security| 0 | Yes |
|--------------+-----------+--------------------|
| LWM2M Server | 1 | Yes |
|--------------+-----------+--------------------|
|Access Control| 2 | Yes |
|--------------+-----------+--------------------|
| Device | 3 | No |
|--------------+-----------+--------------------|
| Connectivity | 4 | No |
| Monitoring | | |
|--------------+-----------+--------------------|
| Firmware | 5 | No |
|--------------+-----------+--------------------|
| Location | 6 | No |
|--------------+-----------+--------------------|
| Connectivity | 7 | No |
| Stats | | |
+--------------+-----------+--------------------+
Figure 1: Standard Device Management Objects
+--------------+----+--------+----------+-------+
|Resource Name | ID | Access | Multiple | Type |
| | | type | instance | |
|--------------+----+--------+----------+-------|
| Latitude | 0 | Read | No | Dec |
|--------------+----+--------+----------+-------|
| Longitude | 1 | Read | No | Dec |
|--------------+----+--------+----------+-------|
| Altitude | 2 | Read | No | Dec |
|--------------+----+--------+----------+-------|
| Uncertainty | 3 | Read | No | Dec |
|--------------+----+--------+----------+-------|
| Velocity | 4 | Read | No | Dec |
|--------------+----+--------+----------+-------|
| Timestamp | 5 | Read | No | Time |
+--------------+----+--------+----------+-------+
Figure 2: Location Object Definition
In addition to these standard objects, OMA working groups, third
party organisations (such as working groups and research groups in
the IETF/IRTF) and enterprises can define their own object
descriptions and register them with the OMA Naming Authority.
Lindgren & Ahlgren Expires May 18, 2018 [Page 6]
Internet-Draft LWM2M for ICN Management November 2017
3.2. LWM2M Functionality
LWM2M introduces the following key features of LWM2M that can be
relevant for the management of IoT devices using an information-
centric networking architecture.
3.2.1. Bootstrapping
A key functionality in LWM2M is the ability to bootstrap and
configure IoT devices in a resource efficient manner. When a IoT
device that has not been configured before connects to a new network,
it will connect to the bootstrap LWM2M server and send a client
initiated bootstrap request by performing a CoAP post to a specific
URI. This URI can for example be hardcoded into the software that is
distributed to all new devices by a manufacturer or operator. The
bootstrap process will install the necessary objects onto the LWM2M
client if they are not already in place, including objects that
specify which LWM2M server to connect to and necessary access
credentials for that. The identity of the connecting device (and
possible access rights) can be established through keys stored in
flash or a smart card (such as the SIM card in a phone).
3.2.2. Device registration and disconnection
When a device has been bootstrapped and knows which LWM2M server to
connect to and has the security credentials to do so, it will connect
to the server using CoAP and send a Registration message that
contains its identity and a list of the objects that the server
should be able to access. The server returns a URI that the device
will use for future communication with the server during this
session. The server maintains this session as a soft state with a
timeout (the duration of which can be modified by the client), so the
device needs to periodically update the server to ensure that the
session is kept established. If a device wishes to disconnect from
the server, it sends a Delete message.
3.2.3. Object access by server
When a device has registered to the LWM2M server, it provides a list
of its objects that it wants the server to be able to access. The
server can Read, Write, or Execute the objects, depending on their
permitted access modes. By reading resources from objects at a
client, the server can collect state information from the device and
by writing content to the resources, the server can configure the
functionality of the device. The Read/Write/Execute commands are
mapped directly to Get/Put/Post messages within CoAP.
Lindgren & Ahlgren Expires May 18, 2018 [Page 7]
Internet-Draft LWM2M for ICN Management November 2017
3.2.4. Observing objects
In many cases, the server wants to monitor the state of the client to
detect important changes that may require reconfiguration of the
device or some other part of the system. To enable this, a publish/
subscribe-like Observe command is available where the server can
choose to observe a particular resource in an object and receive a
notification from the client if that resource changes.
4. Using LWM2M Functionality for ICN Setup
In this section we will outline the possible uses of LWM2M for ICN,
which we mainly see in three categories. Bootstrapping and
configuration is the most obvious way to use the LWM2M protocol in
order to manage IoT devices and set up the required ICN parameters.
There are however other challenges in ICN that LWM2M also have a
potential to address, so we will also briefly discuss the possibility
to use LWM2M as a directory service for ICN applications and as a
transport mechanism on top of which to run ICN as an overlay.
4.1. Configuration of CCN properties for IoT devices
Once initial bootstrapping has been taken care of, the LWM2M device
connects to the specified LWM2M server and sends a Registration
command to let the server know that it is available and ready to be
configured for CCN. The Registration contains the name of the device
and a list of objects that it wants the server to be able to access
(depending on the application, the device may want to give the server
access to objects that are not directly related to CCN, such as the
Location object). The server will access the instances of the CCN
Setup object and other objects to which it has been granted access
and configure the device accordingly by writing configuration
information into the appropriate fields of the object (all of this
done through simple CoAP GET/PUT commands). To properly define a CCN
Setup Object, an application would need to be submitted to the OMA
Naming Authority, but a proposal of what the fields would be is shown
in Table Figure 3. The main pieces of information that need to be
configured are:
CCN prefix: A prefix that should be used for all CCN data objects
that are produced and published by this device.
Default CCN next-hop: The address of the default next-hop CCN router
that should be used by interest messages generated at this device.
This information can possibly be superseeded or not configured by
the server if a network level protocol to detect this exists.
Lindgren & Ahlgren Expires May 18, 2018 [Page 8]
Internet-Draft LWM2M for ICN Management November 2017
CCN routing information: Specific forwarding rules for CCN interest
message forwarding. Multiple instances of this resource can
exist. This information can possibly be superseeded by forwarding
information set up by a network level routing protocol.
Security credentials: Keying material for signing and encrypting
published content, if required by the application.
Network parameters: Gives the possibility for the server to set
network parameters such as the timeout of Interest packets and the
number of retransmissions that should be attempted before giving
up on a request.
Data stream names: Read-only resource that the client uses to
communicate which data streams it will publish under the CCN-
prefix, including any meta-data needed to describe those streams.
+--------------+----+--------+----------+--------+
|Resource Name | ID | Access | Multiple | Type |
| | | type | instance | |
|--------------+----+--------+----------+--------|
| CCN Prefix | 0 | R/W | No | String |
|--------------+----+--------+----------+--------|
| Next-hop | 1 | R/W | No | String |
|--------------+----+--------+----------+--------|
| Route info | 2 | R/W | Yes | JSON |
|--------------+----+--------+----------+--------|
| Security | 3 | R/W | Yes | JSON |
|--------------+----+--------+----------+--------|
| Network param| 4 | R/W | No | JSON |
|--------------+----+--------+----------+--------|
| Data stream | 5 | R | Yes | String |
| name | | | | |
+--------------+----+--------+----------+--------+
Figure 3: CCN Setup Object Definition
Note that some fields are mainly of importance to producers of
content while others are mainly of use to consumers of data. Since a
single device may take on one or both of these roles depending on the
application, the same object is used for all configuration. Exactly
how the server knows how to populate the fields in this object is to
some extent up to the application that will be using data from the
devices as it knows best how to structure the names and topology. A
resource like the CCN prefix can be either predefined based on a
node's identity or role within the organisation, or it can be
dynamically assigned based on properties of other objects at the
Lindgren & Ahlgren Expires May 18, 2018 [Page 9]
Internet-Draft LWM2M for ICN Management November 2017
device that the server has access to. One such example would be to
use the Location object of the device to determine in which region a
device is located and set the CCN prefix accordingly so that data is
published into the CCN domain based on the region in which it was
sensed. A method for using LWM2M to configure the prefix and
additionally set up assymmetric keys to allow nodes to sign data to
provide publisher authenticity and validate that they have the right
to publish data under a certain prefix is defined in
[draft-lindgren-t2trg-lwm2mkeys]. As long as the IoT devices have
sufficient computational resources to perform public key
cryptography, they SHOULD use this method.
The server can then choose to Observe a resource of the device, which
sets up a subscription so that any change of that resource causes the
device to inform the server of this change so that it can take action
(for example update the CCN prefix in the case of location-based
names).
4.2. Configuration of CCN routers
While LWM2M is mainly designed to facilitate the management of IoT
devices, we believe that there are also potential benefits in using
the protocol to manage the local network infrastructure. One of the
challenges in routing and forwarding of interest messages in an IoT
network where the producers may be mobile is that it is very
difficult to maintain accurate routing state. In particular for edge
CCN routers to accurately know what content name prefixes are being
produced downstream since the IoT device itself may not be directly
connected to the router. Using LWM2M, it would be possible for
routers to register with the LWM2M server and receive updated routing
state when a new content stream is available from a connected device.
Depending on the size of the network and the dynamic nature of
content streams and user mobility, scalability might be an issue for
such a solution, so this needs to be studied further.
4.3. LWM2M as an ICN directory service
Similarly as in the router configuration case, a general challenge in
using ICN for IoT applications is that the application needs to know
the name of the data it wants in order to be able to request it.
This is not always easy, especially if data is named based on device
identity and the application is interested in getting data based on
some metadata or if the application just is not aware of which data
is currently available. Since the devices provide information about
their state and the data stream names they will publish, it would be
possible to build a directory service that applications can use to
find the name of the data stream that they want to access. Devices
can also periodically update the sequence number in each data stream
Lindgren & Ahlgren Expires May 18, 2018 [Page 10]
Internet-Draft LWM2M for ICN Management November 2017
so that applications that want to probe for the latest sequence
number get a hint on where to start. This update does not have to be
very frequent and can be done when the device updates its connection
with the server anyway, it is still useful for applications to know a
recent sequence number to avoid having to explore the whole sequence
number space.
4.4. Running LWM2M over ICN
LWM2M is currently defined to run as an application layer protocol
using CoAP messages over IP. This means that for the system
considered in this draft to be possible, those protocols need to be
present in the protocol stack. The CoAP messages used in LWM2M are
however semantically similar to what can be achieved with interest/
data messages, in particular if Named Function Networking (NFN)
functionality is present. Therefore, it would be interesting to also
consider the possibility to run LWM2M directly over an ICN
architecture.
5. Future Work and Realisation Plans
This draft has provided a first study in which the feasibility of
using the functionality of the OMA LWM2M protocol and architecture to
improve deployability, operation, and security of information-centric
networking (in particular the CCN architecture). In the future, we
want to take this closer to realisation in operational systems.
We want to explore ways to evaluate this in real implementations.
Such support can be potentially included as a further service in the
developed security software modules from the EIT Digital ACTIVE
activity and we will also look at how to integrate LWM2M
functionality with the implementation of CCN-lite that we are
currently running on the Contiki OS for IoT devices.
6. Security Considerations
...
7. Acknowledgements
The work behind and the writing of this document are in part
supported by the activity `ACTIVE' within EIT Digital and the Vinnova
GreenIoT project.
Lindgren & Ahlgren Expires May 18, 2018 [Page 11]
Internet-Draft LWM2M for ICN Management November 2017
8. Informative References
[Ahl-icn-survey-commag]
Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D.,
and B. Ohlman, "A Survey of Information-Centric
Networking", IEEE Communications Magazine Volume 50,
Number 7, July 2012.
[draft-lindgren-icnrg-designchoices]
Lindgren, A., Ben Abdesslem, F., Ahlgren, B., Schelen, O.,
and A. Mohammed Malik, "Requirements and Challenges for
IoT over ICN", Internet Draft draft-lindgren-icnrg-
designchoices-00, November 2015.
[draft-lindgren-t2trg-lwm2mkeys]
Lindgren, A., "Key Setup for Publisher Authenticity in
Name-based IoT Publishing Systems using OMA Lightweight
M2M", Internet Draft draft-lindgren-t2trg-lwm2mkeys-00,
September 2017.
[draft-zhang-icnrg-iot-requirements-00]
Zhang, Y., Raychadhuri, D., Grieco, L., Baccelli, E.,
Burke, J., Ravindran , R., Wang, G., Lindgren, A.,
Ahlgren, B., and O. Schelen, "Requirements and Challenges
for IoT over ICN", Internet Draft draft-zhang-icnrg-iot-
requirements-00, November 2015.
[lwm2m] "OMA Lightweight M2M Specification",
http://www.openmobilealliance.org/release/LightweightM2M/
V1_0-20170208-A/OMA-TS-LightweightM2M-V1_0-20170208-A.pdf,
2017.
[mosko2015ccnx]
Mosko, M., Solis, I., Uzun, E., and C. Wood, "CCNx 1.0
protocol architecture", PARC Technical Report
http://www.ccnx.org/pubs/CCNxProtocolArchitecture.pdf,
2015.
[mqtt] Banks, A. and R. Gupta, "OASIS Standard MQTT Version 3.1.1
Plus Errata 01", http://docs.oasis-
open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html, 2015.
Authors' Addresses
Lindgren & Ahlgren Expires May 18, 2018 [Page 12]
Internet-Draft LWM2M for ICN Management November 2017
Anders F. Lindgren
RISE SICS AB
Box 1263
Kista SE-164 29
SE
Phone: +46707177269
Email: anders.lindgren@ri.se
URI: http://www.sics.se/~andersl
Bengt Ahlgren
RISE SICS
Box 1263
Kista SE-164 29
SE
Phone: +46703141562
Email: bengta@sics.se
URI: http://www.sics.se/people/bengt-ahlgren
Lindgren & Ahlgren Expires May 18, 2018 [Page 13]
