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 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
2.  Service discovery using ND
    2.1.  Approach 1: piggy-backing
    2.2.  Approach 2: SD as ND
3.  Service descriptions
4.  Discussion
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgements
8.  Informative References
§  Author's Address

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] (Shelby, Z., Chakrabarti, S., and E. Nordmark, “Neighbor Discovery Optimization for Low-power and Lossy Networks,” April 2010.) 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 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

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.

• a verbose (e.g. XML-based) description of a service, or
• 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 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.

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

Author's Address