[nbs] Working out a part of the name-based approach.

[Javier Ubillos <[e-mail]>]

Hi everyone.

This list has been resting for a while now.

I'd like to (re-)kick start things with a few questions to you all.

At which layer should a name-based approach be at?

The way I see it, we already have a name-based interface in the high
level languages. However, these implementations are typically unilateral
and non-dynamic (in the id/locator-split sense).

I guess we're trying to shoot three monsters at the same time:

* A name-based network programming interface
* An (simple) id/locator-split framework (not hard-defining names to be
  FQDNs)
* A standardized way to check for bilateral support. E.g. to allow
signaling for integrated protocols.




These are the topics we've tried to address with the current name-based
sockets prototype.
Another decision in there was to place the bilateral-support check in
the network-layer. Which on the major OSes means kernel-space.
I guess this is bound to wherever one chooses to have the multiplexing
point for the id/locator split.

This also has implications for distribution, e.g. if we choose the
multiplexing point above the transport protocols, it can easily be
distributed as a user-space library to be used by applications.



Currently, we are still developing the name-based sockets prototype.
We have integrated it with shim6, multi-path TCP, and happy-eye balls.
We are looking at improving details and complementing naming
infrastructures, keeping DNS compatibility, but making names require
less infrastructure/overhead.

// Javier Ubillos