Configuration and service discovery of IPv6 capable sensors
draft-nieminen-core-service-discovery-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Basavaraj Patil , Carles Gomez , Johanna Nieminen , Markus Isomaki , Teemu Savolainen , Zach Shelby | ||
| Last updated | 2011-10-31 (Latest revision 2011-10-24) | ||
| Replaces | draft-nieminen-6lowpan-service-discovery | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nieminen-core-service-discovery-01
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]