NDNSD

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] (#Assumption)

[Design Goals] (#Design-Goals)

[Design specification] (#Design-Specification)

[Technical specification] (#Technical-Specification)

### Assumption: 

   - IP Multicast capable links on a subnet. 

   - (Devices will use a multicast face from NFD)

   - Devices already bootstrapped and have obtained authorized application names

   - Routes for all the application names already exist in the network.

### 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: 

1.  All the devices in the network looking to i) discover service ii) announce service ii) do both, run a discovery application written on top of the discovery library capable of adapting to different sync protocols. 

2. **Producer**

	1.  Application joining as a producer, depending upon service type it wants to advertise, will join a desire sync group. e.g., printer applications can use sync prefix (e.g. /\<root-prefix>/discovery/printer ) specific to printers to advertise their service.

	2. Evey sync group namespace will have a root-prefix prefix. e.g. */dunn-hall/netlab/* , */myhome/*, */uofm/dunn-hall/first-floor/* followed by discovery/\<service-name>.

	    e.g /dunn-hall/netlab/discovery/\<device-name> / ---> /dunn-hall/netlab/discovery/printer1

	          /uofm/dunn-hall/netlab/\<device-name> / ---> /uofm/dunn-hall/netlab/printer1/ ;the device name is a unique name given to each device by the bootstrapping protocol.

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

	4. Applications will use the API provided by the discovery library to publish under the application name prefix. The frequency of the publish interval is controlled entirely by the discovery application. The current producer API consists of following properties, 

        | Property                | Description  |

|------------------ |-------------|

| Service Name       |  Broader service producer is interested in e.g. printer|

| Application Prefix | Legitimate name of producer obtained from the bootstrap process |

| Flags                      | List of flags such as protocol choice, application type, etc.|

| Service Info           | Information about the service, can be a JSON file or text|

| Timestamp            | publication or update timestamp|

| Service lifetime     | How long will service be active?|

| Callback                 | Publish status callback from discovery to application |

	5.  Once the publication is received from the producer app, discovery lib perform the following tasks

		1.  Store or update the publication information i.e. service name, info, application prefix, timestamp and lifetime locally. This will be later used to serve the request that comes for the application name.

		2.  Joins a sync group constructed from the service name. (at the point we assume that the producer will supply a valid service name)

		3.  Start listening on the corresponding application name prefix.

		Note: The reason behind the discovery library listening on application prefix instead of the application itself is to hide the network level abstraction from the application while still leveraging the full network primitives.

	6.  The publication is propagated by discovery lib with the help sync protocol to all other nodes listening on the same sync group prefix. And hence, all the nodes in the network will be synchronized to the latest update.

	7.  When the producer receives an interest for the application prefix it is listening on, it performs the following tasks:

		1.  Check if the service has expired.

		Status = current_time() - publish_time() > lifetime ? EXPIRED : ACTIVE

		2.  Bundles up the info and status in a TLV data and sends it back to the requester.

		3.  If the prefix has expired since a long time, send an application NACK. (need more discussion)

3. **Consumer**

	1. Applications trying to discover a particular service, will use consumer API provided by the discovery library to send its query. 

	2.  The current consumer API looks like following,

        | Property | Description  |

|--|--|

| Service Name |  Service consumer is interested to discover|

| Flags | List of flags such as protocol choice, application type, etc |

| Callback | Callback containing application details i.e. service name, info, and status (active or passive) for each name from the sync data. |

	3. Once the query is received by the discovery lib, it performs the following tasks

		1.  Constructs a sync interest from the service name and fetches the sync data containing all the application names for the same.

		2.  Iteratively sends interest to all the application names and fetches the corresponding details. (these details are bundled up in a TLV and are sent by the corresponding producer (2.7). For more details, refer to the technical details section below).

		3.  And finally, sends the corresponding details of each application to the consumer in the callback.

				**Example:**  

				Sync interest (e.g. I: /dunn-hall/netlab/discovery/printer )

				Sync Data:  

			```

			Data (D): name = /dunn-hall/netlab/discovery/printer/ 

					content: /printer-red/<seq-num>, 

			    			 /printer-blue/<seq-num>

			```

			Iteratively fetching for each application name:

			```				

			Interest (I): /printer-red/

			Data (D): name = /printer-red/

			Content: <Info>: “HP Laserjet 400”, <Status>: Active

4.  Additionally, sync can also piggyback the data content for each application prefix so that consumer applications can avoid sending a separate interest to fetch content. This will also speed up the whole process. (redmine: [5089](https://redmine.named-data.net/issues/5089))

5. **Both**

	1.  Application register as both ie. consumer and producer, is pretty much similar to the producer. But in addition, unlike producer, whenever an update for the sync group is received via sync protocol, discovery lib will iteratively fetch all the updates and send it back to the application.

	2.  Application to be considered both specifically needs to be the part of the same sync group.

Throughout this process, the sync protocol acts as a transport service propagating the updates. It gives great relief to the application. It can absolutely avoid dealing with low-level network primitives while still leveraging all the services offered by it via sync API.