Subject: [icnrg] ICN routing and locators

From: <[email-masked]>
Date: Fri, 24 Jun 2016 22:53:53 +0000

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

---

From: Ravi Ravindran <[email-masked]>
Date: Sat, 25 Jun 2016 00:06:02 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, June 24, 2016 3:54 PM
To: [email-masked]
Subject: [icnrg] ICN routing and locators

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.

Marc

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Jun 2016 10:52:06 -0700

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, <[email-masked]> <[email-masked]> wrote:
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: <[email-masked]>
Date: Mon, 27 Jun 2016 18:31:56 +0000

Thank you!  

This might be an attractive option when considering ICN in today’s IP networks as an overlay.  If EIDs can be expanded to more general formats, like x.500 DNs, then that’s something we should follow up on.

Marc

> On Jun 27, 2016, at 10:52 AM, Dino Farinacci <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 27 Jun 2016 11:47:01 -0700

> 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

---

From: Cedric Westphal <[email-masked]>
Date: Mon, 27 Jun 2016 19:26:12 +0000

Hi Mark,

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

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?

Marc