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

### 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. Basically, here the sync will be used as a Blackbox.

2. **Producer**

	1.  Application joining as a producer, depending upon service type it wants to advertise, will join a sync group. e.g., a printer application will use sync prefix specific to printers to advertise their service.

	2. 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. 

	3. Additionally, applications can also query the network to know about all the services (technically sync groups) available in the network and can choose among the right ones. How does this work?

		A well-known sync group */\<root-prefix>/discovery* (anchor group) will keep track of all the services available in the network. When an application tries to join a sync group, it can fetch all the available groups and choose the right one to join. If a right group doesn’t exist, or if it wants to create a new one, it can easily do so. Once created, */\<root-prefix>/discovery* will also be updated to include this new group. This feature has several benefits but most importantly it will help consumers/producers search for a specific group/s and join without requiring out-of-band knowledge.

		(In future, anchor group can also keep track of services and the respective sync protocol they are using)

	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 |

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

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

	| Timestamp | Service publication or update timestamp|

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

	| Callback | Publish status to application callback from discovery|

	5.  Once the publish are received from the producer, discovery lib perform the following tasks

		1.  Store or update the published 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.  Join or create a new sync group from the service name.

		3.  Start listening on the corresponding application name prefix.

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

	6.  The updates are propagated by discovery 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 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 and sends it back.

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

3. **Consumer**

	1. Applications only trying to discover a particular service, will use the consumer API of the discovery library to send its query with service name and required flags. Additionally, if the consumer doesn’t know the exact service name, it can ask the discovery library for all the available service names and choose the right one. This is facilitated by steps 2.c.

	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 following tasks

		1.  Constructs a sync interest from the service name and fetches the sync data containing all the application names under a particular sync group (service)

		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.g). 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 that of producer. But in addition, unlike producer, whenever an update in the sync group is received via sync protocol, discovery lib will iteratively fetch 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.