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]