CoRE Working Group J. Nieminen, Ed. Internet-Draft B. Patil Intended status: Standards Track T. Savolainen Expires: April 26, 2012 M. Isomaki Nokia Z. Shelby Sensinode C. Gomez Universitat Politecnica de Catalunya/i2CAT October 24, 2011 Configuration and service discovery of IPv6 capable sensors draft-nieminen-core-service-discovery-00 Abstract The number and type of Internet connected devices continues to grow rapidly. Sensors are a new category of devices that are becoming Internet connected. While sensors have existed for a long time, it is only now that we see sensors being capable of communicating via an IP stack. Sensors are used in a multitude of industries and applications. By enabling these devices to be Internet connected, they open up new vistas in terms of applications and uses. Most sensors are generally small with minimal power and processing capabilities. The ability to configure these devices is a challenge. However, in order to make the usage and deployment of Internet connected sensors easier, it is essential that there exist a well defined configuration, control, and service discovery mechanism. This document illustrates various use cases of sensors in different types of deployments and a solution for configuring and controlling them in addition to the ability for sensors and devices to discover services. 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 Nieminen, et al. Expires April 26, 2012 [Page 1] Internet-Draft Sensor service discovery October 2011 material or to cite them other than as "work in progress." This Internet-Draft will expire on April 26, 2012. Copyright Notice Copyright (c) 2011 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Nieminen, et al. Expires April 26, 2012 [Page 2] Internet-Draft Sensor service discovery October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Sensor communication models . . . . . . . . . . . . . . . . . 5 3.1. Local reporting, local consumption . . . . . . . . . . . . 5 3.2. Local reporting, remote consumption . . . . . . . . . . . 6 3.3. Local reporting, cloud backend . . . . . . . . . . . . . . 6 3.4. Cloud service . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Cloud service with control . . . . . . . . . . . . . . . . 7 3.6. Cloud service, direct control . . . . . . . . . . . . . . 7 4. Sensor configuration . . . . . . . . . . . . . . . . . . . . . 7 5. Resource and service discovery . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Nieminen, et al. Expires April 26, 2012 [Page 3] Internet-Draft Sensor service discovery October 2011 1. Introduction During the recent years, mechanisms for connecting sensors with the Internet of Things (IoT) have been developed and standardized. 6LoWPAN standard [RFC4944] defines how to run IPv6 over 802.15.4 family radios (ZigBee, Wireless HART) and [I-D.ietf-6lowpan-btle] proposes a solution for adapting 6LoWPAN stack for ultra-low power Bluetooth Low Energy (BT-LE). However, being able to transmit IPv6 packets is not enough for providing a complete Internet connectivity solution for the sensors. Mechanisms such as sensor configuration, control, resource and service discovery are a crucial part of the solution. This document describes the typical communication models between sensors and the Internet and discusses the related functional and technical requirements. 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 1.2. Terminology Bluetooth Low Energy Bluetooth Low Energy is a low power air interface technology specified by the Bluetooth Special Interest Group (SIG). BT-LE is specified in Revision 4.0 of the Bluetooth specifications (BT 4.0). Gateway Network element connecting sensors to the Internet. Can be e.g a home gateway or a mobile device. 6LR and 6LBR These terms correspond to those defined in [I-D.ietf-6lowpan-nd] Watcher Network element monitoring the state of the sensors. Can be e.g a server or a mobile device. Nieminen, et al. Expires April 26, 2012 [Page 4] Internet-Draft Sensor service discovery October 2011 2. Problem statement Sensors are generally purpose built devices which have very limited processing power, memory or battery life. There are various types of sensors and they can communicate either via a wired or wireless interface. Sensors for detecting temperature, luminescence, humidity, hazardous chemicals, heartrate, pulse etc. are just a few examples. They can be used in a variety of industries and applications including healthcare, automobile, manufacturing, home and enterprise, aviation and agriculture. As sensors become Internet connected, it also brings up the need for them to be configured and managed in an easy manner. The nature of these devices results in configuring, controlling and managing them especially challenging. The applicability of sensors when Internet connected increases dramatically. However, the problem associated with configuring and controlling/managing them needs to be solved in order to make usage and deployment easier. Sensors do not have keyboards or a UI through which they can be configured. The IP stack and capabilities of many of these sensors is also very limited. Hence the problem to be solved is primarily about a protocol or method to configure such barebone sensors which are capable of connecting to the Internet. 3. Sensor communication models This section presents the typical communication models between sensors and the Internet. 3.1. Local reporting, local consumption In this scenario everything happens within a local/private network. Sensor sends data to the local server, watcher in the local network can access the data. Sensor can use local-network discovery methods to locate the server. +--------------+ +--------------+ +--------------+ | Watcher |<----->| Server |<---| Sensor | | | | | | | +--------------+ +--------------+ +--------------+ ____________ / \ | Internet | \____________/ Nieminen, et al. Expires April 26, 2012 [Page 5] Internet-Draft Sensor service discovery October 2011 Figure 1: Local reporting, local consumption 3.2. Local reporting, remote consumption In this scenario the sensor still sends data to a local server. However, the watcher can read the data from anywhere. The server needs to be reachable from the Internet (e.g. via a proxy or Firewall/NAT bindings). ____________ +--------------+ / \ +--------------+ +--------------+ | Service |<--|--Internet---|->| Server/ |<---| Sensor | | | \_ ___________/ | Gateway | | | +--------------+ +--------------+ +--------------+ Figure 2: Local reporting, remote consumption 3.3. Local reporting, cloud backend In this scenario the sensor still sends data to a local server. The local server acts as a gateway and forwards data to an Internet service. The watcher can obtain data from the service. ____________ +--------------+ / \ +--------------+ +--------------+ | Service |<--|-|-Internet--|--| Server/ |<---| Sensor | | | \_|___________/ | Gateway | | | +--------------+ | +--------------+ +--------------+ | +--------------+ | | Watcher |<----| | | +--------------+ Figure 3: Local reporting, remote consumption Nieminen, et al. Expires April 26, 2012 [Page 6] Internet-Draft Sensor service discovery October 2011 3.4. Cloud service In this scenario the sensor communicates directly with the server, requiring configuration. The gateway is transparent and it's main role is to forward packets. The watcher obtains data from the service. ____________ +--------------+ / \ +--------------+ +--------------+ | Service |<--|-|-Internet--|--|---Server/----|----| Sensor | | | \_|___________/ | Gateway | | | +--------------+ | +--------------+ +--------------+ | +--------------+ | | Watcher |<----| | | +--------------+ Figure 4: Cloud service 3.5. Cloud service with control This scenario is similar to the previous scenario with the difference that the watcher/controller can control the sensor via the service. The control can be synchronized with the communication pattern of the sensor or it can be asynchronous. 3.6. Cloud service, direct control This scenario is similar to the previous scenario with the difference that control can happen directly via the gateway. The gateway can act as a proxy to the sensor. 4. Sensor configuration There has to be a self-initiated self-configuration procedure for the initial configuration after sensor start or when the sensor wakes up after being turned off for a longer period of time. One possibility is to hard-code basic parameters such as IP address of the service and transmission frequency in the sensor. Even more simple method would be to hard-code gateway URI in the sensor. The URI would contain more detailed configuration data. Reconfiguration can be performed using CoAP GET and PUT messages. Depending on the communication model being applied, the service or the gateway can be Nieminen, et al. Expires April 26, 2012 [Page 7] Internet-Draft Sensor service discovery October 2011 responsible for the reconfiguration. In some cases the service or a watcher wants to poll a specific data in the sensor cyclically. This could be done by the service/watcher either with a CoAP GET or automatically in a similar fashion as an SNMP trap. Since the same sensor can be connected to several services, it could also be useful if n servers may write to the configuration database of one sensor after negotiating appropriate configuration parameters based on a joint optimization. One important case to consider is how to inform changed IP address of the gateway or service. Usually such devices have the possibility to get the server IP address from DHCP options. It might be beneficial to provide a CoAP server with similar responsibility on IP addresses. If DHCP is used, then the sensor would just have to redo the DHCP query after the wake-up (i.e. instead of using names and DNS for discovery, DHCP might work for some cases). I.e. in both cases the client would not stuck to specific IP, but would find the IP for a name or a service dynamically. As DNS records have time to live, the DHCP information might also have some time to live so that it would not have to be rerequested just after short sleep and if point of connection to Internet has not changed. 5. Resource and service discovery Besides configuration, it is important to consider how the gateway or a watcher can identify names, states and capabilities of objects, groups of objects and services (example: identify which sensors are attached to an HVAC system of a particular house) One possibility is to use a protocol with multicast capability which sends out a query within the scope of a gateway or watcher and wait for responses from the sensors. The Sensors should wake up if they are in sleep mode and respond to such a query with a response which describes the sensors functionality and service provided. 6. IANA Considerations This document does not require any IANA actions. 7. Security Considerations Configuration and control of sensors have to be done in a secure manner. The ability to hijack a sensor by malicious entities is a threat and can be fairly critical depending on the type of sensor and Nieminen, et al. Expires April 26, 2012 [Page 8] Internet-Draft Sensor service discovery October 2011 application that it is being used in. Service discovery also needs to have security in terms of ensuring that the service is authentic and being offered by a valid entity. Various types of threats exist in an environment where sensors are Internet connected and these can vary depending on the scenario and method through which the sensor obtains connectivity. 8. Acknowledgements 9. Normative References [I-D.ietf-6lowpan-btle] Nieminen, J., Patil, B., Savolainen, T., Isomaki, M., Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets over Bluetooth Low Energy", draft-ietf-6lowpan-btle-03 (work in progress), October 2011. [I-D.ietf-6lowpan-hc] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN)", draft-ietf-6lowpan-hc-15 (work in progress), February 2011. [I-D.ietf-6lowpan-nd] Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)", draft-ietf-6lowpan-nd-17 (work in progress), June 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, Nieminen, et al. Expires April 26, 2012 [Page 9] Internet-Draft Sensor service discovery October 2011 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, September 2007. Authors' Addresses Johanna Nieminen (editor) Nokia Itaemerenkatu 11-13 FI-00180 Helsinki Finland Email: johanna.1.nieminen@nokia.com Basavaraj Patil Nokia 6021 Connection drive Irving, TX 75039 USA Email: basavaraj.patil@nokia.com Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere Finland Email: teemu.savolainen@nokia.com Markus Isomaki Nokia Keilalahdentie 2-4 FI-02150 Espoo Finland Email: markus.isomaki@nokia.com Nieminen, et al. Expires April 26, 2012 [Page 10] Internet-Draft Sensor service discovery October 2011 Zach Shelby Sensinode Hallituskatu 13-17D FI-90100 Oulu Finland Email: zach.shelby@sensinode.com Carles Gomez Universitat Politecnica de Catalunya/i2CAT C/Esteve Terradas, 7 Castelldefels 08860 Spain Email: carlesgo@entel.upc.edu Nieminen, et al. Expires April 26, 2012 [Page 11]