Re: [icnrg] ICN routing and locators

[Dino Farinacci <[e-mail]>]

> Thank you!  
> 
> This might be an attractive option when considering ICN in today’s IP networks as an overlay.  If EIDs 

But you don’t need to use the data-plane if you don’t want to. You can use the LISP mapping database solely as a control-plane tool. So rather than injecting object-ids into a routing protocol in a push fashion (where I’m understanding ICN is struggling with aggregation and state), you can use a pull database that isn’t stored in every switching node.

And if you look at LISP-DDT, you can use an object-id allocation hierarchy that can map well for layers between “/“ slashes. Very much like DNS but more general and has pub/sub notification features.

> can be expanded to more general formats, like x.500 DNs, then that’s something we should follow up on.

They certainly can with no protocol changes.

Dino

> 
> Marc
> 
>> On Jun 27, 2016, at 10:52 AM, Dino Farinacci <[e-mail]> wrote:
>> 
>> You could have a look at the LISP mapping database system. We have many different EID-record types that can be registered with the mapping system. Here are two recent types we just added.
>> 
>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-name-encoding
>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-geo
>> 
>> Certainly a ICN named object can be encoded as a distinguished-name in the LISP mapping system.
>> 
>> Let us know if the LISP WG can help you all out!
>> 
>> Thanks,
>> Dino
>> 
>>> On Jun 24, 2016, at 3:53 PM, <[e-mail]> <[e-mail]> wrote:
>>> 
>>> 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.
>>> 
>>> 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
>>> _______________________________________________
>>> icnrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/icnrg
>> 
>