Subject: [icnrg] Name resolution and name based routing in ICN - A discussion (reformatted version)

From: Börje Ohlman <[email-masked]>
Date: Fri, 27 Oct 2017 15:10:45 +0000

Name Resolution has been a longstanding topic in ICN, so the chairs would like to encourage a discussion about name resolution and its potential utility to ICN and its specific instantiations, without presuming any particular name resolution architecture and protocol properties. We would like to have a longer discussion on this at the interim meeting in Singapore. Please let us know if you would be willing to make a short discussion starter presentation of your view of this.

Some background:

In ICN, names can represent different things, including Named Data Objects (NDOs), nodes, functions (or their results). Names can also be related to other names in a variety of ways, including collections, alternative names for the same data, various forms of indirection, and discovery. While each of these “name computation” or “name lookup” functions could be provided in a number of ways, for example, by an application-specific function on a per-application basis, by a function-specific lookup service (e.g. “link objects”, or discovery services) there are also a set of functions that manipulate names in order to enable scalable routing in an ICN. These are the functions we have been discussing under the rubric of a “Name Resolution Service/System”, or “NRS”.

When consumers issue Interests for these named things, we expect the network to forward those interests to a suitable place in the network that generates a corresponding Data message. Forwarding Information can be built leveraging different information sources: name-based routing, name resolution, SDN control, static configuration etc. Sometimes, none of this is needed (for example in broadcast or local rendezvous-based systems). In other cases, a combination of different inputs and mechanisms could be useful.

Whereas the different techniques have their individual merits and potentials issues (scalability,  lookup latency, communication overhead etc.), there are also architectural considerations and implications:

  *
Does relying on a name resolution system imply that we always have to resolve names to identifiers in a different namespace? Conversely, is a name resolution system ever needed to map names to a different namespace (specifically the namespace of lower-layer services such as IP or Ethernet).
  *
Are there specific privacy and security implications with particular approaches? Whenever a level of indirection is added to a system, there is potential to expand the attack surface dramatically, as now there are opportunities to attack the provenance of the input namespace, the output namespace, andthe translation mechanisms and protocols themselves.
  *
Who does the resolution?
  *
Is NRS a new architectural entity that requires new protocols and semantics in current ICN systems?
  *
Does NRS imply some mutability of Interest messages (name rewriting?) and what would be the implications?
  *
What is the level of integration with the routing system? Are the results of an NRS operation intended to be used just to construct tunnels (e.g. the routing system is oblivious other than possibly calling the NRS to identify tunnel endpoints) or is the routing system intimately entwined, as it would be with routing hints in Interest messages.
  *
Relying solely on Name Based Routing (NBR) poses a number of yet not resolved issues. Some of these are general in the sense of fundamental to the scaling of routing state*rate; others are specific to the structure of namespaces in an ICN architecture. These issues include, but are not limited to:
     *
Global scalability of routing
     *
Producer mobility
     *
Finding off-path cached objects
     *
Security (specifically authorization) of routing information injected from outside the routing system.

Existing material on this topic includes:

  1.
Requirements for Name Resolution Service in ICN - https://datatracker.ietf.org/doc/draft-jhong-icnrg-nrs-requirements/

Looking forward to your input and comments,
     Börje, Dave & Dirk

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg