NDN Service Discovery (NDNSD)¶

NDNSD is a service discovery library for NDN based devices and applications. It uses the sync protocol to disseminate publication and discovery updates. Thus, it can also be viewed as a wrapper library on top of the sync libraries.

Assumption
Design Goals
Design specification

Assumption:¶

• IP Multicast capable links on a subnet.
• (Devices will use multicast face from NFD)
• Devices already bootstrapped and have obtained authorized application names

Design Goals:¶

• Applications should be able to i) advertise services ii) look for the service provided by others iii) select and invoke the desired service.
• The data received via the discovery process should be authentic and secure.

Design specification:¶

• All the devices in the network wanting to discover service, announce service or do both, run a discovery application written on top of the discovery library capable of adapting to different sync protocols. Basically, here the sync will be used as a Blackbox.

• Depending upon the type of their service, they join a particular sync group. e.g. , the printer application will use sync prefix to advertise their service. Evey sync group namespace will have a root-prefix that is either context-dependent (e.g. /dunn-hall/netlab/ ), local (e.g. /myhome/ ), or globally reachable (e.g. /uofm/dunn-hall/first-floor/ )

   Sync group prefix: /<root-prefix>/discovery/printer
   e.g. /dunn-hall/netlab/discovery/printer (locally reachable)
        /uofm/dunn-hall/first-floor/discovery/printer (globally reachable)
  

  Note: our assumption is that the devices are already bootstrapped, and have obtained application name/s that they are allowed to publish the data under. Authorized application name can be:

    e.g /uofm/library/iprint/<device-name>/
       /uofm/dunn-hall/netlab/<device-name>/
  

  The device name is a unique name given to each device by the bootstrapping protocol.

• Applications willing to publish services will use the full-sync API provided by the sync protocol/s, and will publish data under the application name prefix. The frequency of the publish interval can be periodic or as desired. Additionally, a chronologically increasing sequence number is attached in each publication internally by the sync protocol. e.g. /uofm/library/iprint/printer-red/1 <- seq-number.

• The updates are propagated by the sync protocol to all other nodes listening on the same sync prefix. And hence, the nodes in the network will be synchronized to the latest update.

• Applications only trying to discover services will simply send a sync interest (e.g. I: /dunn-hall/netlab/discovery/printer ) to the desired sync groups, and finds out all the latest updates by all the applications belonging to the same group. Example: Data for the above interest may look like

  Data (D): name = /dunn-hall/netlab/discovery/printer/
            content: /printer-red/<seq-num>, 
                     /printer-blue/<seq-num>
  

  Here the sync protocol acts as a transport service propagating the updates. The application absolutely doesn’t have to deal with low-level network primitives while still leveraging all the services offered by it via sync API.

• Once the sync data is received by an application, it can fetch the content specific to each update on the user prefix (/printer-red/). Additionally, sync can also piggyback the data content for each application prefix so that applications can avoid sending a separate interest to fetch content. This will also speed up the whole process.

• Applications willing to do both i.e. publish and discover services will perform both steps 3, 4 and 5. Basically, it will set an interest filter on the particular sync group prefix that it serves - meaning listening for an interest. And when it publishes an update, it will satisfy the pending sync interest. Similarly, it will also periodically (or as desired) send a sync interest to get the latest updates from all the nodes in the network.

Design specification:¶