6LoWPAN Working Group J. Nieminen, Ed.
Internet-Draft B. Patil
Intended status: Standards Track T. Savolainen
Expires: April 23, 2012 M. Isomaki
Nokia
Z. Shelby
Sensinode
C. Gomez
Universitat Politecnica de
Catalunya/i2CAT
October 21, 2011
Configuration and service discovery of IPv6 capable sensors
draft-nieminen-6lowpan-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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 2012 [Page 11]