CoRE Working Group J. Nieminen, Ed. Internet-Draft B. Patil Intended status: Standards Track T. Savolainen Expires: May 3, 2012 M. Isomaki Nokia Z. Shelby Sensinode C. Gomez Universitat Politecnica de Catalunya/i2CAT October 31, 2011 Configuration and service discovery of IPv6 capable sensors draft-nieminen-core-service-discovery-01 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 May 3, 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 May 3, 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 May 3, 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, Internet service . . . . . . . . . . . . 6 3.4. Internet service . . . . . . . . . . . . . . . . . . . . . 7 3.5. Internet service with ability to control the sensor . . . 7 3.6. Internet service, direct sensor control . . . . . . . . . 7 4. Sensor configuration . . . . . . . . . . . . . . . . . . . . . 7 5. Resource and service discovery . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Nieminen, et al. Expires May 3, 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] Consumer Network element monitoring the state of the sensors. Can be e.g a server or a mobile device. Nieminen, et al. Expires May 3, 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, consumer in the local network can access the data. Sensor can use local-network discovery methods to locate the server. +--------------+ +--------------+ +--------------+ | Consumer |<----->| Server |<---| Sensor | | | | | | | +--------------+ +--------------+ +--------------+ ____________ / \ | Internet | \____________/ Nieminen, et al. Expires May 3, 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 consumer can read the data from anywhere. The server needs to be reachable from the Internet (e.g. via a proxy or Firewall/NAT bindings). ____________ +--------------+ / \ +--------------+ +--------------+ | Consumer |<--|--Internet---|->| Server/ |<---| Sensor | | | \_ ___________/ | Gateway | | | +--------------+ +--------------+ +--------------+ Figure 2: Local reporting, remote consumption 3.3. Local reporting, Internet service 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 consumer can obtain data from the service. ____________ +--------------+ / \ +--------------+ +--------------+ | Service |<--|-|-Internet--|--| Server/ |<---| Sensor | | | \_|___________/ | Gateway | | | +--------------+ | +--------------+ +--------------+ | +--------------+ | | Consumer |<----| | | +--------------+ Figure 3: Local reporting, Internet service Nieminen, et al. Expires May 3, 2012 [Page 6] Internet-Draft Sensor service discovery October 2011 3.4. Internet 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 consumer obtains data from the service. ____________ +--------------+ / \ +--------------+ +--------------+ | Service |<--|-|-Internet--|--|---Server/----|----| Sensor | | | \_|___________/ | Gateway | | | +--------------+ | +--------------+ +--------------+ | +--------------+ | | Consumer |<----| | | +--------------+ Figure 4: Internet service 3.5. Internet service with ability to control the sensor This scenario is similar to the previous scenario with the difference that the consumer/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. Internet service, direct sensor 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 The sensor runs a simple application that communicates for instance using the CoAP protocol. At minimum the application requires some basic configuration to operate properly. The configuration includes parameters such as the IP address, hostname or the URI of the server or gateway the application should send its requests to. In many cases the sensor also has to have the proper credentials to succesfully communicate with the service. If the sensor only communicates with the hosts in its local Nieminen, et al. Expires May 3, 2012 [Page 7] Internet-Draft Sensor service discovery October 2011 environment, mechanisms such as well-known multicast addresses or DHCP migth work for the sensor application to get its initial configuration. These correspond to the "local reporting" communication models described in hte previous section. However, when the sensor application should communicate directly with a server or service across the Internet, with no relation to the access network the sensor is attached to, the situation becomes more challenging. For instance, a heart rate meter would need to be configured with the fitness service provider's domain name or URI, and the credentials of its current user, so that its data is sent to the right place with the correct privacy settings. This corresponds to the basic configuration of e-mail or SIP or XMPP accounts. The difference is that a sensor such as a heart rate belt does not have the user interface to input even these basic parameters. One approach is to use another device with better user interface to assist with the configuration. Many devices such as home routers are currently configured in this manner. The routers runs a web server and another host attached to the same LAN can access it with a web browser, usually using some obscure hard coded IP addresses to start with. Running even a simple web server and a set of web pages on it may however not be practical for a limited sensor. Instead, simpler mechanisms may be needed. For instance, the proper configuration might be manually input or automatically fetched to a device such as a PC or smartphone, where the sensor could discover and fetch it. As the sensors are expected to use CoAP for their normal service communication, it would be sensible for the server to use the same protocol for fetching the configuration object. For this to work, there may be need to standardize these aspects: 1. How the sensor can discover that its default gateway or some other host in its local environment can offer it configuration for the correct type of service. 2. How the sensor fetches the configuration. 3. Format of the basic configuration: Server URI, credentials. CoAP alredy offers the basic mechanisms for what is needed here, but small amount of additional standards development seems necessary to get all of this interoperable. 5. Resource and service discovery Besides configuration, it is important to consider how the gateway or a consumer can identify names, states and capabilities of objects, Nieminen, et al. Expires May 3, 2012 [Page 8] Internet-Draft Sensor service discovery October 2011 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 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 Nieminen, et al. Expires May 3, 2012 [Page 9] Internet-Draft Sensor service discovery October 2011 (6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress), October 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, "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 Nieminen, et al. Expires May 3, 2012 [Page 10] Internet-Draft Sensor service discovery October 2011 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 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 May 3, 2012 [Page 11]