[Ndn-interest] topology-independent and autoconfiguration service assigned temporary namespaces in NDNFit.

Muhammad Hosain Abdollahi Sabet M.AbdollahiSabet at mail.sbu.ac.ir
Thu Aug 20 07:16:43 PDT 2015


Thanks for the reference.
So I suppose there should be something like using method 3 mentioned in the link. Then the node will obtain a topology-independent prefix mentioned earlier to have the ability to publish data and be accessed from local or global(via NDNS and Link obj) network, right?

Since the publisher mobility is my focus, I'm more interested in dealing with topology-independent namespaces. As far as I understand, topology-independency, which brings us naming consistency -and that's crucial for publisher mobility- is achieved in the cost of having non-aggregatable names. So we will probably have some prefixes(for other applications like mHealth) in intermediate FIBs which each of those are responsible -in the worst case- maybe just for one user, right? Isn't it sound more burden on routing system?
Are these topology-independent names FIB records going to have lifetime or something? If not so, with publisher being relocated, interests may be routed to invalid paths.

p.s: What is the need for encapsulating data packets? Data packets could return following breadcrumbs. Previous versions of SNAMP talks about encapsulating _Interest_ packets, which is disregarded in the last version. 


-----Original Message-----
From: Burke, Jeff [mailto:jburke at remap.ucla.edu]
Sent: Thu 8/13/2015 8:43 PM
To: Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu
Subject: Re: topology-independent and autoconfiguration service assigned temporary namespaces in NDNFit.

A good starting point for the current auto-configuration support is here:
There are some plans to extend it in the future, which I imagine will be documented in a future tech report.   In some scenarios, auto configuration could be envisioned to provide a device with one or more namespaces under which it can publish and have interests from the global internet (or the enterprise, or...)  reach it.  This is I think what a "temporary" namespace referred to in this case.

The term "topology-independent" was used in this use case to describe a namespace used for mhealth data that may or may not be globally routable.  It could be communicated by 1) globally routing the namespace 2) using the namespace in local communication 3)  encapsulating data named using it within one or more globally routable namespaces and using a link-type object to provide one level of indirection for requestors.   The motivation in the Open mHealth scenario is to created a long-lived namespace that is provider-independent (analogous, say, to registering a domain or subdomain but being able to switch hosting provider).    This is early work and will be fleshed out further in the coming months.

How these types of namespaces could be used together in something like the Open mHealth scenario is a little more involved and something that hopefully will be written up in a tech report later in the Fall.


From: Muhammad Hosain Abdollahi Sabet
Date: Thursday, August 13, 2015 at 4:20 AM
To: "ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>", Jeff Burke
Subject: topology-independent and autoconfiguration service assigned temporary namespaces in NDNFit.

There are some summarized explanations about NDNFit in annual progress report 2015 which I'm not sure if I've understood well. I've seen
too, but that is an older version.
There is this notion of _topology-independent namespace_ in 2.6 which is a mean to allow mobile producers to publish contents without the need for changing prefixes. According to Fig.2.6 b this namespace would be􀀗􀀄 _org/openmhealth_. In 2.2.1 there is a mention of _autoconfiguration support_, the NDN equivalent for DHCP. Fig. 2.7 says it's going to _provide temporary namespace and key for publishing while roaming._
First, what is the difference between topology independent and this temporary namespaces? Second, Is this service going to be an application specific and how to find the correspondent server would be preconfigured?

There are some other questions which are dependent to answers of the ones above.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150820/6ef911cc/attachment.html>

More information about the Ndn-interest mailing list