Re: [icnrg] ICN routing and locators

[Cedric Westphal <[e-mail]>]

Hi Mark,

I am interested in discussing this, and continuing the conversation from Dagstuhl. One point below…

From: icnrg [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Friday, June 24, 2016 3:54 PM
To: [e-mail]
Subject: [icnrg] ICN routing and locators

At this year’s Dagstuhl seminar (and prior years I understand), there has been talk about locator/identifier separation in ICN.  I would like to get feedback from ICNRG if we should continue to discuss this and see if there’s any consensus on the topic.

The main issue related to this is how to use names in content/data objects that do not exist in the core routing tables, but do exist in some edge network(s) or edge nodes.  Two other related issues to this topic are supporting mobility and exploiting off-path copies of content (assuming routing only points towards an authority).


1)      Some suggest that using compact network-independent routing could be sufficient.  These support application-assigned names with modest routing stretch. After first contact via the compact routing scheme, nodes may use topology-aware labels to speed up communications (i.e. stretch 1 routing with very small labels) [e.g. the Tagnet approach].  [see, for example, https://csperkins.org/research/thesis-msci-mooney.pdf]

CW: I have some fondness for compact routing, and since the 2010 MS thesis you are citing, there are a couple interesting results, including:
J. Herzen, C. Westphal, P. Thiran, Scalable routing easy as PIE: a Practical Isometric Embedding protocol, in Proc. of IEEE ICNP'11, Vancouver, BC, October 2011
C. Westphal, G. Pei, Scalable Routing Via Greedy Embedding, in Proc. IEEE Infocom 2009
The first paper in particular has very small path stretch and is robust to topology changes and forwarding operations are extremely simple.

CW: One issue is to reconciliate using a compact routing schemes that involves having topology-aware names for nodes, with the idea of having content  names in the routing layers. Another issue is that if you are going to dissociate routing names (locators) and content names, then why not use IP at the routing layer?



2)       NDN proposes NDNS (a DNS/DANE like system) to distribute signed link objects that are used in map-and-encap to route an Interest across the default-free zone (DFZ) to a region that can satisfy the original Interest predicate. The link is put in a modifiable portion of the Interest called the “selected delegation.” [see http://named-data.net/wp-content/uploads/2015/03/SNAMP-NDN-Scalability.pdf]



3)       CCNx has been promoting nameless objects, where a Content Object without a name may be retrieved by an Interest with any name and a hash restriction.  It’s been noted that this mode is similar to a NetInf approach.  This means the name in the Interest could identify a location in some cases or an object in others.  There is not a specified method yet for distributing those locator names to use to find nameless objects, though there is some talk of using an NRS (could be like NDNS) method or tracker services.



4)       There are some proposals [draft-ravi-ccn-forwarding-label-02] in ICNRG to add a forwarding label field to an Interest in CCNx.  This would provide functionality like the NDN link.  The formation of the forwarding label (FL) is actually very similar to the NDN link, though it does not have mandatory signing and it uses the terms locator/identifier whereas the NDN link uses the term map-and-encap.


5)       There is also in ICNRG the “hybrid naming” proposal [draft-zhang-icnrg-hn-04.txt].  Although this splits the name between 3 pieces (hierarchical, flat, and attributes), I do not think it addresses having a changeable part based on current attachment of the data source.

One could probably show that #2 NDN link and #4 forwarding label are about the same as #1, as compact routing schemes like TZ and many others work by assigning a landmark some short distance away from a destination, then route towards the landmark then from the landmark to the destination (except they require an external NRS).  That’s essentially what the links do, though without the formal properties of compact routing.


In case #1, I think we can just keep going as we’re going and punt to routing.  In cases #2 - #4, I think we could consolidate options if desired.  If nothing else, we could close the gap between #2 NDN link and #4 forwarding labels.  Case #5 on hybrid naming I think needs to describe how mobility, off-path caching, and non-globally routable names work.

Marc