[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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.


   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

   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

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

   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

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

   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

              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

   Phone: +358 9 451 2481
   Email: jukka.manner@tkk.fi
   URI:   http://www.netlab.tkk.fi/~jmanner/

Manner                   Expires April 22, 2010                 [Page 7]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/