Project

General

Profile

Wiki » History » Version 10

Saurab Dulal, 04/10/2020 02:38 PM

1 10 Saurab Dulal
NDN Service Discovery (NDNSD)
2
=============
3
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.
4
5
[Assumption] (#Assumption)
6
[Design Goals] (#Design-Goals)
7
[Design specification] (#Design-Specification)
8
[Technical specification] (#Technical-Specification)
9
10
### Assumption: 
11
   - IP Multicast capable links on a subnet. 
12
   - (Devices will use a multicast face from NFD)
13
   - Devices already bootstrapped and have obtained authorized application names
14
15
### Design Goals:
16
  - Applications should be able to i) advertise services ii) look for the service provided by others iii) select and invoke the desired service.
17
  -  The data received via the discovery process should be authentic and secure.
18
19
### Design-Specification: 
20
21 5 Saurab Dulal
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.
22 1 Saurab Dulal
2. **Producer**
23 3 Saurab Dulal
	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.
24 1 Saurab Dulal
	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/* )  
25 9 Saurab Dulal
	   
26
	     Sync group prefix: /\<root-prefix>/discovery/printer
27
	     e.g.  /dunn-hall/netlab/discovery/printer  (locally reachable)
28
	             /uofm/dunn-hall/first-floor/discovery/printer  (globally reachable)
29 4 Saurab Dulal
	     
30 9 Saurab Dulal
	    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:
31 1 Saurab Dulal
32 9 Saurab Dulal
	    e.g /uofm/library/iprint/\<device-name>/
33
	          /uofm/dunn-hall/netlab/\<device-name>/ ;the device name is a unique name given to each device by the bootstrapping protocol. 
34
35 1 Saurab Dulal
	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?
36 9 Saurab Dulal
    
37
38 8 Saurab Dulal
		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.
39
40 9 Saurab Dulal
		(In future, anchor group can also keep track of services and the respective sync protocol they are using)
41 8 Saurab Dulal
	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, 
42 9 Saurab Dulal
	
43
	| Property | Description  |
44
	|--|--|
45
	| Service Name |  Broader service producer is interested in e.g. printer|
46
	| Application Prefix | Legitimate name of producer obtained from the bootstrap |
47
	| Flags | List of flags such as protocol choice, application type, etc.|
48
	| Service Info | Information about the service, can be json file or text|
49
	| Timestamp | Service publication or update timestamp|
50
	| Service lifetime | How long will service be active?|
51
	| Callback | Publish status to application callback from discovery|
52 8 Saurab Dulal
53
54 1 Saurab Dulal
	5.  Once the publish are received from the producer, discovery lib perform the following tasks
55 8 Saurab Dulal
		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.
56 9 Saurab Dulal
		    
57 8 Saurab Dulal
		2.  Join or create a new sync group from the service name.
58
		3.  Start listening on the corresponding application name prefix.
59
60 1 Saurab Dulal
		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.
61 9 Saurab Dulal
	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.
62 8 Saurab Dulal
		    
63 9 Saurab Dulal
	7.  When the producer receives an interest for the application prefix it is listening on it performs following tasks:
64 8 Saurab Dulal
		1.  Check if the service has expired.
65
		Status = current_time() - publish_time() > lifetime ? EXPIRED : ACTIVE
66
		2.  Bundles up the info and status in a TLV and sends it back.
67
		3.  If the prefix has expired since a long time, send an application NACK. (need more discussion)
68
3. **Consumer**
69 9 Saurab Dulal
	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.
70 8 Saurab Dulal
	2.  The current consumer API looks like following,
71
72 9 Saurab Dulal
	| Property | Description  |
73
	|--|--|
74
	| Service Name |  Service consumer is interested to discover|
75
	| Flags | List of flags such as protocol choice, application type, etc |
76
	| Callback | Callback containing application details i.e. service name, info, and	 	status (active or passive) for each name from the sync data. |
77 8 Saurab Dulal
78 9 Saurab Dulal
	3. Once the query is received by the discovery lib, it performs following tasks
79 8 Saurab Dulal
		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)
80
		    
81
		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).
82
	    
83
		3.  And finally, sends the corresponding details of each application to the consumer in the callback.
84
				**Example:**  
85
				Sync interest (e.g. I: /dunn-hall/netlab/discovery/printer )
86
				Sync Data:  
87
			
88
			```
89
			Data (D): name = /dunn-hall/netlab/discovery/printer/ 
90
					content: /printer-red/<seq-num>, 
91
			    			 /printer-blue/<seq-num>
92
			```
93
			Iteratively fetching for each application name:
94
		
95
			```				
96
			Interest (I): /printer-red/
97
			Data (D): name = /printer-red/
98
			Content: <Info>: “HP Laserjet 400”, <Status>: Active
99
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))
100
5. Both
101
	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.
102
	2.  Application to be considered both specifically needs to be the part of the same sync group.
103 1 Saurab Dulal
104 9 Saurab Dulal
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.