[nbs] Working out a part of the name-based approach.
Javier Ubillos <firstname.lastname@example.org> Wed, 01 June 2011 08:10 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6760AE06F2 for <email@example.com>; Wed, 1 Jun 2011 01:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([18.104.22.168]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovkmbksy0zg5 for <firstname.lastname@example.org>; Wed, 1 Jun 2011 01:10:04 -0700 (PDT)
Received: from letter.sics.se (letter.sics.se [22.214.171.124]) by ietfa.amsl.com (Postfix) with ESMTP id 57593E075A for <email@example.com>; Wed, 1 Jun 2011 01:10:04 -0700 (PDT)
Received: from [192.168.0.224] (h69n1-haes-a12.ias.bredband.telia.com [126.96.36.199]) (Authenticated sender: firstname.lastname@example.org) by letter.sics.se (Postfix) with ESMTPSA id EE51F400E2; Wed, 1 Jun 2011 10:10:02 +0200 (CEST)
From: Javier Ubillos <email@example.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-7Wss9DFf0C7zKSw1pQOO"
Date: Wed, 01 Jun 2011 10:10:00 +0200
X-Mailer: Evolution 2.30.3
Subject: [nbs] Working out a part of the name-based approach.
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nbs>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2011 08:10:05 -0000
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
- [nbs] Working out a part of the name-based approa… Javier Ubillos
- Re: [nbs] Working out a part of the name-based ap… Denis Martin
- Re: [nbs] Working out a part of the name-based ap… Javier Ubillos