Network Working Group J. Jimenez Internet-Draft M. Ocak Intended status: Informational Ericsson Expires: December 3, 2016 June 01, 2016 Software Update Experiences for IoT draft-jimenez-iotsu-soft-exp Abstract This document provides a summary of found problems and possible solutions for software upgrades on the constrained space. Some of the issues are still open and should be subject of discussion. Ideally some implementation guidelines should be made when using CoAP [RFC7252], HTTP [RFC7230] or MQTT as transfer protocols. The sections are purposedly left short as they are open issues that should be discussed. 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 December 3, 2016. Copyright Notice Copyright (c) 2016 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 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 Jimenez & Ocak Expires December 3, 2016 [Page 1] Internet-Draft draft-jimenez-iotsu-soft-exp June 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Dealing with Sleepy endpoints . . . . . . . . . . . . . . . . 3 4. Device Initiated Communication . . . . . . . . . . . . . . . 3 5. Manager Initiated Communication . . . . . . . . . . . . . . . 3 6. Delegation on other nodes . . . . . . . . . . . . . . . . . . 4 7. Using Multiple Stacks . . . . . . . . . . . . . . . . . . . . 4 8. Runtime Discovery . . . . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 10. Informative References . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction In this short paper we try to raise some issues we have found when dealing with software upgrades in the IoT domain. Dealing with sleepy endpoints is at Section 3. The case for device initiated communication is on Section 4 and manager initiated on Section 5. Delegation on gateways or other nodes is in Section 6. The use of an alternative stack for software upgrades is at Section 7. A possible long-term architecture that enables to do runtime updates on the constrained device is at Section 8 2. Architecture We start with the assumption of a device that is constrained but does not require gateways for communication as it uses some operator-based connectivity (though we do not assume SMS transport). Device Manager +--------------------+ +--------------------+ | CoAP Server/Client | | CoAP Server/Client | +--------------------+ +--------------------+ | UDP | +-----------------> | UDP | +--------------------+ +--------------------+ | IPv4/IPv6 | <-----------------+ | IPv4/IPv6 | +--------------------+ +--------------------+ | 4G/NB-IoT | | ANY | +--------------------+ +--------------------+ This simple, generic set up presents several problems, specially when dealing with the operator environment. We enumerate some of them below. Jimenez & Ocak Expires December 3, 2016 [Page 2] Internet-Draft draft-jimenez-iotsu-soft-exp June 2016 3. Dealing with Sleepy endpoints The fact that devices are sleepy poses several problems for doing software updates. Namely that you do not have a connected endpoint most of the time and that therefore the device will have to contact the manager or the manager will have to poll the device pretty frequently. The case for polling does not scale and therefore it is hardly a solution. Nevertheless it is very common to use polling on the constrained space since the server has more capabilities and thus can query the device providing that there are no NATs or firewalls (See Section 4) 4. Device Initiated Communication The first issue are NATs and Firewalls. Constrained devices do not have the capabilities nor the inclination to punch holes through NATs and keep them open, that task has to be delegated elsewhere. What we have done in order to overcome this obstacle is to set an observation on the device. Assuming that the device has previously registered on a Resource Directory (RD) [I-D.ietf-core-resource-directory] that the manager has access to, the manager would then observe the status of the device (0:off, 1:on). Whenever the device wakes up it will send a notification to the manager. During the time the NAT is open the manager will be able to send data through the holes in the NAT. D<--M: CoAP GET /Radio_link_status, Token: 0x4a, Observe: 0 D-->M: 2.05 Content, Token: 0x4a, payload: 1, time: 1464619477 D-->M: 2.05 Content, Token: 0x4a, payload: 1, time: 1464520998 5. Manager Initiated Communication NATs and Firewalls are persistent issues to resolve also in manager initiated communication. However, we could re-use the capabilities of CoAP to overcome this issue. In this approach, there is no need to set a separate observation on the status of the device as defined in Section 4. When the device sends a notification to any existing observation on any resource, the manager can initiate the software update during the established connection through NAT. This approach requires the manager to implement the logic of linking observation of any resource to send software update to the device. Jimenez & Ocak Expires December 3, 2016 [Page 3] Internet-Draft draft-jimenez-iotsu-soft-exp June 2016 6. Delegation on other nodes Many of the IoT devices may not have connectivity to the manager and gateways are used to provide such connectivity to the manager in the e.g. core network. Gateways used in this use case are more capable to perform complex operations and to support different protocol stacks together, which can be used to update the device software. For our implementation we assumed that the gateway supports, at least, both CoAP and HTTP stacks. The communication between the device and the gateway is performed using CoAP. Gateway can retrieve the software update from the manager through HTTP without NAT issues and cache the downloaded package. One other way for the gateway to retrieve the software package could be to observe software update resource on the manager via CoAP observe option. The manager notifies the gateway with CoAP notifcation when there is a software update available. When the device wakes up and connects to the gateway, the gateway can push the cached software update to the device. However, this approach requires the Gateway to have the required credentials to perform such software update operation. This can be achieved e.g. by having a CoAP proxy on the Gateway. Gateway retrieving software package via HTTP: G-->M: HTTP GET /swupdate G<--M: 200 Content, payload: swpackage D<--G: COAP POST /sw, Token: 0xbb, payload: swpackage Gateway retrieving software package via CoAP Observe option: G-->M: COAP GET /swupdate, Token: 0x6a, Observe: 0 G<--M: 2.05 Content, Token: 0x6a, payload: swpackage D<--G: COAP POST /sw, Token: 0xbb, payload: swpackage 7. Using Multiple Stacks We have seen how in some cases devices have multiple stack combinations and updates go through an "alternative channel". For example: MQTT+HTTP in this scenario MQTT is used as the base protocol for communication. Having publish/subscribe architecture simplifies the (1:n) and (n:1) communication use cases that are very common for reporting sensor data. For firmware upgrades a command is sent to the device with the URL where the new binaries are (i.e. https://company/devicetype/version00.zip), the device then sets a Jimenez & Ocak Expires December 3, 2016 [Page 4] Internet-Draft draft-jimenez-iotsu-soft-exp June 2016 whole different communication channel just for that, as well as a dedicated DTLS/TLS connection. This is too much overhead for many constrained devices. MQTT+CoAP similar to previous scenario, MQTT is the base protocol for communication and firmware upgrade command is sent to the device in an MQTT message, which includes the CoAP URL to the binary to be downloaded. The device opens a UDP connection to the CoAP endpoint and downloads the binary with e.g. CoAP blockwise transfer. This scenario may occur when the node serving the software package supports only CoAP. 8. Runtime Discovery Instead of sending bulk binaries with several megabytes of data, a simpler approach would be to send partial modifications related to the software update when possible. Similarly as it was shown in the IOTSI Workshop [IOTSIWS], Runtime Discovery is also a very powerful mechanism to provide updated services and software to a device. A device could use a single entry point for its firmware information (e.g. "/fw"), then device would periodically perform discovery on that point and in order to discover new capabilities. Links to the new capabilities could be discoverable on demand. Only very basic semantics would be shared a-priori. Current software upgrade mechanism do not allow for changes at runtime. There are predefined interfaces that would break whenever the API changes, making it compulsory to send new software to the device that would need to install it, reboot, etc. The device logic has to support such interfaces, no changes are possible at runtime. 9. Acknowledgements Runtime Discovery ideas are inspired from Matthias Kovatsch's presentations on HATEOAS at [IOTSIWS]. Thanks to Carsten Bormann and Jari Arkko for the valuable feedback. 10. Informative References [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Resource Directory", draft-ietf-core-resource-directory-07 (work in progress), March 2016. Jimenez & Ocak Expires December 3, 2016 [Page 5] Internet-Draft draft-jimenez-iotsu-soft-exp June 2016 [IOTSIWS] IAB, "IoT Workshop for Semantic Interoperability (IOTSI) - Main Page and Position Papers", 2016, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ RFC7252, June 2014, . Authors' Addresses Jaime Jimenez Ericsson Email: jaime.jimenez@ericsson.com Mert Ocak Ericsson Email: mert.ocak@ericsson.com Jimenez & Ocak Expires December 3, 2016 [Page 6]