One document matched: draft-manner-6lowapp-sdnd-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY nd PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6lowpan-nd.xml'>

]>

<!-- trust200902 --> <!-- full3978 -->

<rfc category="exp" ipr="trust200902" 
docName="draft-manner-6lowapp-sdnd-00.txt">

<!--
<rfc category="exp" ipr="full3978" 
docName="draft-manner-6lowapp-sdnd-00.txt">
-->

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?> <?rfc symrefs="yes" ?> <?rfc sortrefs="yes"?> 
<?rfc iprnotified="no" ?> <?rfc strict="yes" ?> <?rfc compact="yes" 
?>

    <front>
        <title abbrev='SDND'> Coupling of Service and Neighbor Discovery in 6LowPAN </title>

	<author initials='J.' surname="Manner" fullname='Jukka Manner'>
        <organization abbrev='TKK'>Helsinki University of Technology (TKK)</organization>
        <address>
        <postal>
	<street>Department of Communications and Networking (Comnet)</street>
        <street>P.O. Box 3000</street>
        <city>Espoo</city> <code>FIN-02015 TKK</code>
        <country>Finland</country>
        </postal>
        <phone>+358 9 451 2481</phone>
        <email>jukka.manner@tkk.fi</email>
        <uri>http://www.netlab.tkk.fi/~jmanner/</uri>
        </address>
        </author>

        <date month="October" year="2009" />
        <abstract>

	<t>

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 
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.

	</t>

	</abstract>
    </front>

<middle>

<section title="Introduction">

<t>

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.

</t>

<t>

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.

</t>

<t>

The 6Lowpan Neighbour Discovery (ND) <xref 
target="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.

</t> <t>

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.

</t> <t>

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.

</t> <t>

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 
pros and cons, and seeks to trigger some community response from 
6LowApp.

</t>

</section>

<section title="Service discovery using ND">

<t>

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.

</t>

<t>

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.

</t>

<t>

<list style="numbers">

<t>Service query (SQ): sent by a node to look up a service from the 
whiteboard on an ER.</t>

<t>Service reply (SR): sent by an ER to the requesting node 
indicating which, if any, node(s) hosts the service.</t>

</list>

</t>

<t>

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.

</t>

<t>

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.

</t>

<section title="Approach 1: piggy-backing">

<t>

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.

</t>

<t>

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

</t>

<t>

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.

</t>

<t>

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.

</t>

<t>

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.

</t>

</section>

<section title="Approach 2: SD as ND">

<t>

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.

</t>

</section>

</section>

<section title="Service descriptions">

<t>

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.

</t>

<t>

<list style="symbols">

<t>a verbose (e.g. XML-based) description of a service, or</t>

<t>a simple string describing a resource (e.g. "gateway", 
"temperature sensor").</t>

</list>

</t>

<t>

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.

</t>

<t>

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 
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.

</t>

<t>

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.

</t>

<t>

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.

</t>

</section>

<section title="Discussion">

<t>

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.

</t>

<t>

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.

</t>

</section>

<section title="Security Considerations">

<t>

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.

</t>

</section>

<section title="IANA Considerations">

<t>

This document does not make requests to IANA at this stage.

</t>

</section>

<section title="Acknowledgements">

<t>

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).

</t>

</section>

</middle>

    <back>

<!-- <references title='Normative References'>

	&rfc2119;

	</references> -->
        <references title='Informative References'>

	&nd;

	</references>

    </back>

</rfc>