Re: [icnrg] Name resolution and name based routing in ICN - A discussion (final try)

[Jungha Hong <[e-mail]>]

Dear all,


As a author of the draft of NRS requirements, I appreciate chairs initiating this NRS discussion.


I have submitted the updated NRS requirements draft and would like to discuss it in Singapore.

https://www.ietf.org/internet-drafts/draft-jhong-icnrg-nrs-requirements-02.txt


This document describes the motivation and requirements for NRS.

For motivation, we mainly focus on the "Name-based routing", where the Name in ICN is heterogeneous and Name-based routing causes the scalability problem in the routing system. Producer mobility in ICN is another motivation of NRS.


For requirements, I also agree with Yan that it's impossible to have a perfect NRS which meets all the requirements.

So, instead of the word "requirement", what about "design considerations"?

If changes, the document will present things that you may consider when you design a NRS but you don't have to satisfy all.

Depending on your purpose of the NRS, you can choose specific design considerations or requirements.

In this matter, we can expand the draft into the architectual points.

Please give me any kinds of comments on this point.


I have extended the CICN for NRS and wrote a new draft on this: https://www.ietf.org/internet-drafts/draft-hong-icnrg-ccnx-nrs-00.txt

This is an incomplete draft, but the implementation has been almost commpleted.

We kept the TLV-based packet format defined in CCNx Messages  document and modified the forwader to enable the NRS packets working.

So, I would like to discuss and share my experience with the NRS implementation based on CICN in Singapore as well.


I implemented the bloom filter based NRS to support flat name: https://datatracker.ietf.org/doc/draft-hong-icnrg-bloomfilterbased-name-resolution/

Although the draft is expired, I can bring up the experience of its implementaion.


Any comments will be welcomed.


Thanks,

Jungha Hong




________________________________
보낸 사람 : "Börje Ohlman" <[e-mail]>
보낸 날짜 : 2017-10-28 00:31:20 ( +09:00 )
받는 사람 : icnrg <[e-mail]>
참조 :
제목 : [icnrg] Name resolution and name based routing in ICN - A discussion (final try)



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:



  *   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