Re: [icnrg] ICN routing and locators

[Ravi Ravindran <[e-mail]>]

Hi Mark,

Would definitely support this discussion at the ICNRG meeting. I just inserted one comment for #4 which is the forwarding label object proposal in CCN.

Regards,
Ravi

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]



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.



Ravi> One difference from link-object proposal, is that a FL object is modifiable in the network to support late binding. So this can be used towards mobility, service or content name resolution; the reason why we propose it part of the fixed header. The security binding between the name and the locator in the FL object can optionally follow the semantics defined in the link-object proposal.


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