One document matched: draft-manner-6lowapp-sdnd-00.txt
Network Working Group J. Manner
Internet-Draft TKK
Intended status: Experimental October 19, 2009
Expires: April 22, 2010
Coupling of Service and Neighbor Discovery in 6LowPAN
draft-manner-6lowapp-sdnd-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Finding out functionality, nodes or services, in general resources,
in a network has a number of well-known solutions. A sensor network
has inherent limitations and requires a solution that has a low
Manner Expires April 22, 2010 [Page 1]
Internet-Draft SDND October 2009
footprint and follows the networking concepts defined within 6LoWPAN.
This draft discusses two alternative solutions to service discovery
in a sensor network. Both approaches are based on the 6LowPAN
Neighbor Discovery.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Service discovery using ND . . . . . . . . . . . . . . . . . . 4
2.1. Approach 1: piggy-backing . . . . . . . . . . . . . . . . . 4
2.2. Approach 2: SD as ND . . . . . . . . . . . . . . . . . . . 5
3. Service descriptions . . . . . . . . . . . . . . . . . . . . . 5
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Manner Expires April 22, 2010 [Page 2]
Internet-Draft SDND October 2009
1. Introduction
Service discovery has been a research topic for years. Currently the
topic is rather well understood and we have had products on the
market for years, Universal Plug and Play (UPnP) being the most well-
known example. In the IETF, the Service Location Protocol (SLP) is
probably the most familiar outcome of activities in this area, yet,
the protocol does not seem to have had a tremendeous deployment.
If we look at the landscape in service discovery for resource
constrained devices, such as nodes in a sensor network, there exists
many proposal from the academic community. However, they all seem
somewhat uncessary complex. A 6LoWPAN-based solution should be
simple and enable low overheard, while trying to be as flexible and
powerful as possible within the constraints imposed by the sensor
devices.
The 6Lowpan Neighbour Discovery (ND) [I-D.ietf-6lowpan-nd] describes
means for a sensor node to disseminate it's IPv6 address to the
network, and if needed, defend it against other nodes. The
functionality presented in the ND draft is based on Edge Routers (ER)
that maintain a white board, a database, of addresses claimed in the
sensor network. This makes ND a centralized service. ERs can be
used when the sensor network is connected to a backbone link, but an
ad-hoc sensor network can also have ERs that function as the
centralized address allocation database.
What is interesting about the ND functionality is that it has the
same overall goal as service discovery (SD): a node has a
characteristic, a functionality, it wants to disseminate to other
nodes. This is analoguous to SD, a node has a service it wants to
make known and enable others to use. This is a simplistic view, of
course, but in general the goal of ND is very close to what SD
requires, make a resource known to others (claim it). In ND, an IP
address, a resource, can only be assigned to a single node, but in SD
numerous nodes can host the same resource, the service. In SD, the
possibility of having several nodes host the same resource enables us
to drop much of the more complex ND functionality.
One of the issues with enabling service discovery is how to describe
a service. We need a common means to describe a service when it is
advertised or search for. In a sensor network, we have to rely on
very small messages, thus, lenghty service descriptions are not
possible. We need a means to define services in a compact format.
The purpose of this draft is to discuss two distinct approaches to
enabling service discovery in a 6LowPan-enabled sensor network. The
rest of this draft presents the two alternatives, discusses their
Manner Expires April 22, 2010 [Page 3]
Internet-Draft SDND October 2009
pros and cons, and seeks to trigger some community response from
6LowApp.
2. Service discovery using ND
This section presents two approaches for running SD in a sensor
network, piggy-backing SD payloads in ND messages, or running a
separate SD protocol that has much of the same functionality as ND.
In both cases, there are two commonalities. First of all, we need to
define two new ICMP messages. The structure of these two new
messages would be similar to the ND ICMP messages, only slightly
simpler.
1. Service query (SQ): sent by a node to look up a service from the
whiteboard on an ER.
2. Service reply (SR): sent by an ER to the requesting node
indicating which, if any, node(s) hosts the service.
In both of these messages, we need to have a request ID, or similar
serial number, to match replies to requests. This is needed when a
node is looking for several services, and one SQ can only indicate a
single service to be found; a node can have several outstanding
queries and needs to match incoming replies to the right query.
Secondly, in the normal case the same service can run on more than
one node. Analoguous to the ND specification, we could make use of
the so-called "Duplicate flag" that if set allows more than one host
to offer a certain service. Yet, when the bit is not set, only one
node in the network can host a certain service at a time. Here we
could make use of the DAD functionality of ND and enable nodes to
claim and defend their services.
2.1. Approach 1: piggy-backing
The first approach to enabling service discovery in a sensor network
is to piggy-back service availability information within ND messages.
In particular, when a node sends its IP address information to an ER
(or refreshes it), the node also includes additional information
about the services it is hosting.
The basic functionality for SD would be the same as in ND, i.e.,
nodes announce their services to ERs, and maintain this information
along the refresh messages sent by ND for the IPv6 address mapping.
If a service is taken down from a node, it can send a refresh ND
message
Manner Expires April 22, 2010 [Page 4]
Internet-Draft SDND October 2009
The ND specification mentions but does not define a "Configuration
Option" that may be used to carry options. We can make use of this
particular functionality, or define a separate option that is very
much similar. This option should be stackable, meaning we want to be
able to carry information about more than one service running on a
single node.
The same object would be used on the service lookup message (SQ) to
indicate the service the node is looking for. Only one service can
be looked up in one message, otherwise sending back an answer becomes
complex, as discussed above.
To make service deregistration easier, we could add a bit in the
object above to indicate that the service is not being introduced but
rather an existing binding should be removed from the ER.
2.2. Approach 2: SD as ND
An alternative to the first approach would be to define an SD
protocol that makes use of most of the functionality of ND. In
general, we would re-use from ND the registration (and ack) of IPv6
addresses on ERs, the claiming and defending of services (optional),
and add the SQ/SR messaging. The end result would be quite similar
to ND, on a high level, except that nodes store service availability
on ERs, instead of IPv6 addresses.
3. Service descriptions
A key issue to design is an efficient encoding of the service
descriptions. We do not want to have a verbose format and
expressions in a sensor network. In this respect, we propose to
present services as fixed-size hashes. In particular, a hash can be
calculated from e.g.
o a verbose (e.g. XML-based) description of a service, or
o a simple string describing a resource (e.g. "gateway",
"temperature sensor").
We could also allocate services to pre-defined integer values. This
has the downside that we need to maintain a list of well-known
services, such as an IANA registry. Also, having fixed numbers is
less flexible.
In a sensor network, the typical use cases are about finding a sink
or a gateway (or ER) from a sensor node, or finding a particular
sensor from the gateway. We don't usually have use cases for
situations where a node would be looking for services in general, and
Manner Expires April 22, 2010 [Page 5]
Internet-Draft SDND October 2009
then picking something "interesting" or otherwise random. All use
cases are about finding whether (or actually just where) a particular
service is available in the sensor network.
In some use cases, it might be important to hide the SD messaging, in
particular make it harder to figure out what service a particular
node is hosting, or looking for. If we use a simple hash of a
service description that remains static all the time, an outsider, if
link layer encryption is not used or has been broken, can analyze the
SD messaging and employ statistical analysis to seek to find out the
services available; at least what are the most frequently asked
services.
To make this guessing harder, we can calculate the hash from a more
dynamic data. For example, we could calculate the hash from the
service description or string but also add a further data element to
make each hash in the network different. This way an outsider will
only see a huge number of different service descriptions. An example
for such an additional data element could be the IP address of the
node asking for or providing a service. It would be straightforward
for a legitimate node to dig the actual service information from a
received message, provided it knows the service descriptions that are
used in the sensor network. The use of hashing needs some more study
to fine-tune all details.
4. Discussion
The first approach would be clearly more desirable since it would
allow for code reuse on a sensor node, and limit the amount of bytes
sent due to SD. This would be most beneficial to the sensor nodes
with limited resources. Moreover, specifying a full protocol that
would essentially only carry additional information to ERs along ND
seems like a waste of resources.
If the network does not have ND deployed, we would be forced to
introduce SD as the described separate protocol. If that is the
case, we should aim for a simple messaging and limited functionality,
instead of trying to design a solution that has the same level and
features as, e.g., UPnP.
5. Security Considerations
This draft presents two overall approaches to service discovery. A
detailed security analysis will be done if the work proceeds to
target a protocol specification.
Manner Expires April 22, 2010 [Page 6]
Internet-Draft SDND October 2009
6. IANA Considerations
This document does not make requests to IANA at this stage.
7. Acknowledgements
This work is a joint effort by the FP7 211998 AWISSENET and TKK ISMO
research projects. Ad-hoc PAN and Wireless Secure Sensor Networks
(AWISSENET) is an EU-funded FP7 project. Intelligent Structural
Health Monitoring System (ISMO) is funded by the Multidisciplinary
Institute of Digitalisation and Energy (MIDE,
http://mide.tkk.fi/en/), a technology initiative by the Helsinki
University of Technology (TKK).
8. Informative References
[I-D.ietf-6lowpan-nd]
Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S.,
Bormann, C., and E. Nordmark, "6LoWPAN Neighbor
Discovery", draft-ietf-6lowpan-nd-06 (work in progress),
September 2009.
Author's Address
Jukka Manner
Helsinki University of Technology (TKK)
Department of Communications and Networking (Comnet)
P.O. Box 3000
Espoo FIN-02015 TKK
Finland
Phone: +358 9 451 2481
Email: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Manner Expires April 22, 2010 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 20:13:00 |