User Tools

Site Tools


Problem description

A nodeDB is one of the core services of a community network. A community wireless network has a couple of needs which are covered by a nodeDB:

  • registry functionality: reserve IP addresses, assign nodes and devices to users, register users and their email addresses. As such the nodeDB serves as a database for the network.
  • link planning: this answers the question “if I put a node here, will it work?”
  • CPE provisioning: image generation: automatically generate images / firmware or their respective configuration (in this feature is called “unsolclick”)
  • server config provisioning: central servers such as DNS servers need information from the nodeDB (which devices exist, what are their IPs etc). Services could include:
    • DNS
    • VoIP servers
    • Whois server
    • map service
  • allow people to contact each other in a distributed community network
  • federation: allow services such as DNS zones to be federated across the network
  • monitoring & alerting: devices and central services need to be monitored.
  • One goal should be to have a nodeDB as a “Setup.exe” for new community networks
  • common query-API: a nodeDB needs to speak the standardized query API


Since roughly the year 2000 different community networks have been implementing and re-implementing their own management tools for running community wireless networks. These tools , amongst them you will always find a node database, are non interoperable. It is currently not possible to program one application for one community network and let it “run” with the services and nodeDB of the other community networks. This results in a waste of resources, waste of time and will be a big stumbling block for connecting community networks to each other. Apart from the non-interoperable tools, there the authors identified two other stumbling blocks for connecting community networks (possibly in a federated way):

  • IP addressing schemata: most community networks run on private RFC1918 IP addresses. These will collide when connecting two different community networks. Any future, harmonized nodeDB therefore must take into account the switch to IPv6 which allows the community networks to be connected to each other via IPv6 at least
  • exterior gateway protocol interoperability: BGP (RFC 4271) is not particularly well suited for wireless connections and the change in link quality. However, this topic is outside of the scope of this document and merely mentioned here.

The following document shall describe a harmonized nodeDB implementation and an API for querying this nodeDB. The API SHOULD be implemented by existing nodeDB variants in order to allow for improved interoperability and federation as part of the CONFINE project. The API consists of two parts:

  1. a RESTful query API
  2. two possible answer format for queries: JSON or XML based on the CNML specifications.

In the course of this attempt, the CNML specifications will be expanded (but documented in a different place XXX FIXME: link to CNML?)

Requirements Terminology

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], with the important qualification that, unless otherwise stated, these terms apply to the design of the incident response requirements and design document, not its implementation or application.


nodeDB node database
CNML Community network markup language
node By node we mean a location where multiple devices as well as antennas can be mounted

Previous attempts and history

The interop page at was already a first attempt to get an interoperable nodeDB started. Unfortunately, due to lack of resources, these attempts died off two times.

Overview of existing nodeDB

High level problem description


Use-case ID Short description Explanation
UC1 IP registry A nodeDB MUST implement an IP registry functionality for IPv4 as well as IPv6 addresses.
UC 1.1 get_new_ip() assign data block (contactinfo / device (interface) info) to an IP address (range) which was marked as free –> Allocator
UC 1.2 free_ip() if contact details are associated with IP then, delete that link, mark IP as “free”
UC 1.3 ip_can_be_reclaimed() check, if that IP is not in use anymore –> garbage collector
UC 1.4 get_data_for_ip() return contacts / device (interface) data for that IP (range)
UC 1.5 update_data_for_ip() update the contacts / device (interface) info for that IP (range)

User interfaces

Requierements list


nodedb/reqdocument.txt · Last modified: 2012/07/24 18:32 by aaron