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

From: Börje Ohlman <[email-masked]>
Date: Fri, 27 Oct 2017 15:31:00 +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:

  *   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

---

From: "Z.W. Yan" <[email-masked]>
Date: Mon, 30 Oct 2017 09:33:00 +0800

It’s necessary to have wide discussion about the naming service in ICN/NDN, 
but we also need to narrow the requirements because it’s impossible to have
a perfect naming service which satisfies too many requirements 
(scalable, readable, secure, mobility-supporting, routing…).

As in ICN/NDN, the most important point is “name-based routing”, 
then the naming service should be scalable and efficient enough 
to support this point. I think that should be our main motivation to design the naming service in ICN/NDN.

2017-10-30 

Zhiwei Yan
CNNIC

发件人： Börje Ohlman 
发送时间： 2017-10-27  23:32:02 
收件人： icnrg 
抄送： 
主题： [icnrg] Name resolution and name based routing in ICN - Adiscussion (final try) 

Some background:

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/

---

From: "David Oran" <[email-masked]>
Date: Mon, 30 Oct 2017 12:10:42 -0400

> (scalable, readable, secure, mobility-supporting, routing…).
In general this is a good list and the point that trying to be 
everything to everybody is a path unlikely to succeed is certainly 
valid. This is why we (the chairs) tried to explain the nature of the 
whole design space and then suggest we concentrate on the role of an NRS 
in ICN routing without worrying about some of the other uses identified.

That said, at least some of the attributes/requirements you list above 
are in fact important, if not critical, to solving the problem of an NRS 
applied to ICN routing, so I’m not sure how to pare that list down in 
a useful way.

If you have ideas on how to scope these things for routing more narrowly 
than for a general naming service, those would be great to write down 
and discuss on the mailing list and at the meeting. As a start to that, 
I can suggest a few areas that may yield simplifications:

- the dynamic nature of the forwarding plane may allow an NRS to have 
slower update convergence than one designed for data plane that has to 
protect against transient loops or undetected misrouting. This helps 
with mobility.
- the kinds of mapping stored in an NRS for routing may not need a fully 
general trust schema and hence simpler route validation and key 
management may suffice.
- privacy may be such an intractible problem generally that trying to 
enforce routing privacy through the NRS a waste of time.
- some architectures like CCNx1.0 can avoid certain NRS complexity by 
punting multiple (topological) name assignment to the applications 
rather than trying to solve it in the NRS
- discovery may be better done with a separate custom service rather 
than leveraging an NRS.
- etc.

> design the naming service in ICN/NDN.
I agree that this should be our focus, at least for now.

> 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?
> 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:
> Requirements for Name Resolution Service in ICN - 
> https://datatracker.ietf.org/doc/draft-jhong-icnrg-nrs-requirements/
>

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

DaveO

---

From: Cedric Westphal <[email-masked]>
Date: Mon, 30 Oct 2017 17:33:28 +0000

Börje,

Thanks for starting this discussion.

A couple more things that I would like to highlight as well:

-        Relying on Name Based Routing conflates the name resolution with the routing. In particular, it ensures that the path that the interest follows to find a copy of the content is also the path that the content follows. I believe the implications of this should be better understood, since neither is resolution of the name to a location and the content route are optimized with respect to the other

-        I would insert some discussion on manifests as well, as the name resolution may be mediated through such an object.
Cheers,

C.

From: icnrg [mailto:[email-masked]] On Behalf Of Börje Ohlman
Sent: Friday, October 27, 2017 8:31 AM
To: icnrg
Subject: [icnrg] Name resolution and name based routing in ICN - A discussion (final try)

Some background:

---

From: Jungha Hong <[email-masked]>
Date: Tue, 31 Oct 2017 09:09:47 +0000

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" <[email-masked]>
보낸 날짜 : 2017-10-28 00:31:20 ( +09:00 )
받는 사람 : icnrg <[email-masked]>
참조 :
제목 : [icnrg] Name resolution and name based routing in ICN - A discussion (final try)

Some background:

     Börje, Dave & Dirk

---

From: "Z.W. Yan" <[email-masked]>
Date: Wed, 1 Nov 2017 09:25:46 +0800

Hi, David, I agree with this "route" to design the NRS in ICN/NDN.
From the point of routing support, this issue can be split into two sub-issues:
In order to make sure the name-based routing can be deployment in practice, 
the following principles should be followed (at least):
1) Uniqueness: the name appeared in the public network should be unique.
[Just like in IP/DNS, a management scheme is needed to guarantee the uniqueness of the name in ICN/NDN.]
2) Scalability: the name appeared in the ICN/NDN routing should be restricted.
[Not all the names can be flooded into the FIB. This is also for the routing security consideration.]
3) Mobility: publisher mobility should not be supported directly by routing flooding. 
[Tunneling or other redirection schemes can be used to support publisher mobility to guarantee the stability of the routing.]
......

Then, the following name-based routing architecture may be needed as an example:
1) Hierarchical routing: in the top level, the information of top-level prefixes are exchanged, just like the TLD (Top-level domain in DNS) related routing information. In the lower levels, the information of lower-level prefixes are exchanged. The default out-face of the lower-level routing is its upper-level routing.
2) With the above logic, a name registration scheme is needed to guarantee the uniqueness and validity of the routing names (this scheme may be decentralized in the top-level). And then the upper-level delegates the lower-level.
3) Security in the routing must be considered from the beginning. For example, a route only with a legal certificate can be broadcasted into the network and with border restriction.
[This cannot guarantee the optimized routing, but the fist motivation is to support the routing 
to be scalable with numerous names. In other words, routing should rely on the content delegation/management 
relationship because network topology is more dynamic. In addition, because ICN/NDN supports the content caching, 
reachability is more important than efficiency for the name-based routing.]  

As you siad, we may need something to start.This is just my rough idea to start the discussion, if it mainly makes sense, we can discuss the related details.

BR,
Zhiwei Yan
CNNIC

发件人： David Oran 
发送时间： 2017-10-31  00:22:58 
收件人： Z.W. Yan 
抄送： Börje Ohlman; icnrg 
主题： Re: [icnrg] Name resolution and name based routing in ICN -Adiscussion (final try) 

In general this is a good list and the point that trying to be everything to everybody is a path unlikely to succeed is certainly valid. This is why we (the chairs) tried to explain the nature of the whole design space and then suggest we concentrate on the role of an NRS in ICN routing without worrying about some of the other uses identified.
That said, at least some of the attributes/requirements you list above are in fact important, if not critical, to solving the problem of an NRS applied to ICN routing, so I’m not sure how to pare that list down in a useful way.
If you have ideas on how to scope these things for routing more narrowly than for a general naming service, those would be great to write down and discuss on the mailing list and at the meeting. As a start to that, I can suggest a few areas that may yield simplifications:
the dynamic nature of the forwarding plane may allow an NRS to have slower update convergence than one designed for data plane that has to protect against transient loops or undetected misrouting. This helps with mobility. 
the kinds of mapping stored in an NRS for routing may not need a fully general trust schema and hence simpler route validation and key management may suffice. 
privacy may be such an intractible problem generally that trying to enforce routing privacy through the NRS a waste of time. 
some architectures like CCNx1.0 can avoid certain NRS complexity by punting multiple (topological) name assignment to the applications rather than trying to solve it in the NRS 
discovery may be better done with a separate custom service rather than leveraging an NRS. 
etc. 
As in ICN/NDN, the most important point is “name-based routing”,
then the naming service should be scalable and efficient enough
to support this point. I think that should be our main motivation to design the naming service in ICN/NDN.

Zhiwei Yan
CNNIC

发件人： Börje Ohlman

Some background: