[nbs] A name-oriented API: What should it look like? How should it behave?

Javier Ubillos <jav@sics.se> Wed, 01 December 2010 09:18 UTC

From: Javier Ubillos <jav@sics.se>
To: Name-based Sockets List nbs <nbs@ietf.org>, Christian Vogt <christian.vogt@ericsson.com>, Stefan Götz <stefan.goetz@cs.rwth-aachen.de>, Denis Martin <dmartin@tm.uka.de>, Helge Backhaus <backhaus@tm.uka.de>, Bengt Ahlgren <bengta@sics.se>, Stuart Cheshire <cheshire@apple.com>, Dave Thaler <dthaler@microsoft.com>, Erik Nordmark <erik.nordmark@oracle.com>, Miika Komu <mkomu@cs.hut.fi>, Tobias Heer <heer@cs.rwth-aachen.de>, Saleem Bhatti <saleem@cs.st-andrews.ac.uk>, Mingwei Xu <xmw@csnet1.cs.tsinghua.edu.cn>, Zhongxing Ming <mingzx@126.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-DfKn4KjrTrYsGwBkil5B"
Date: Wed, 01 Dec 2010 10:19:45 +0100
Message-ID: <1291195185.2018.417.camel@bit>
Mime-Version: 1.0
Subject: [nbs] A name-oriented API: What should it look like? How should it behave?
Precedence: list

Hello everyone.

At the name-based sockets BoF (IETF79 November 8th) there was a clear
interest in defining an (abstract) API.
http://www.ietf.org/proceedings/79/minutes/nbs.txt

I wanted to get that discussion started, and I'd like to emphasize that,
at this stage, everything is an open question.
Here's a starting draft in which I intend to capture these discussions.
http://www.ietf.org/id/draft-Ubillos-name-based-api-00.txt

I have tried to synthesize, the feedback during the BoF and the  chats 
afterwards. Thank you Erik Nordmark, Saleem Bhatti, Mika Komu,  Tobias
Heer, David Thaler, Randall Stewart, Stuart Cheshire and everyone who
have argued with me and given me feedback. I greatly appreciate it!



Today we are already seeing name-oriented APIs in all kinds of
application
frameworks, they are very popular.
However, they tend to only leverage app-protocol functionality.
Also, as the service used defines the application-protocol used,
bi-lateral support is implied by the used service. This limits the
functionality
used to application-protocol functionality.

The objective is to make it easier for applications to make use of
networking solutions.

To achieve this *I* believe we need to:

API wise:
   * Provide an API in parallel to the socket() calls.
      * This API should take "names" in different formats.
         * Ability to select resolution system for names

   * The API should be able to receive information about which functions
     the application wants (e.g. multi-homing)

   * The API should be able to provide information
      * About which functions are available.
      * If the remote peer supports the requested features (if
bi-lateral
        support is needed.)
      * About relevant changes (e.g. if the set of locators has changed)

Behavior wise:
   * When a recipient receives a connection, the receiving
socket/application
     receives a simple, unauthenticated session handle.
      * If the application needs more information, it calls some part of
the API
        and is obviously prepared to pay whatever performance cost the
function
        requires.
      * Possible (and optional!) features are:
         * Name exchange
         * Authenticity
         * (you name it...)

   * Making the name-exchange an optional part (and not an integral
part) means
     that it can be done on-demand. Whenever the user or some thing else
     requested by the user requires it.


I believe this also means that we need to have some functionality which
checks for bi-lateral support, and is able to exchange information about
what functions the respective peer wishes to use.

The name-based sockets implementation and draft(s) are attempts to
capture this (however, still incomplete when it comes to API questions).
http://tools.ietf.org/html/draft-ubillos-name-based-sockets-03
http://tools.ietf.org/html/draft-xu-name-shim6-00

// Javier

Attachment: signature.asc

[nbs] A name-oriented API: What should it look li… Javier Ubillos

[nbs] A name-oriented API: What should it look like? How should it behave?

Attachment: signature.asc