Subject: [rrg] hostname oriented stack

From: "William Herrin" <[email-masked]>
Date: Mon, 17 Nov 2008 18:17:49 -0500

Some incomplete thoughts... If we wanted to build a hostname-oriented
stack, how do the components divide up?

Off the top of my head, the components look like:

1. Layer-3 protocol to move packets in which the "addresses" carry
-only- locator semantics. Could possibly use IPv6 here?

2. Locator assignment, reassignment and routing protocol (LARRP) to
recursively assign locator prefixes (from a prefix for the entire
network down to a single locator for a host), reassign them when the
routing topology changes and and keep track of which prefixes map to
which layer-2 destinations from which to build a FIB.

3. Core routing protocol (CRP) to handle routing between entities
which are not assigning addresses to each other. Maybe rolls up into
LARRP, maybe not. CRP used anywhere peering happens today.

4. Service Name Resolution Protocol (SNaRP) - so that initiators can
find the LOCs for their destinations. No real value in keeping the
concept of a "host" at the protocol level. Let that be handled with
naming conventions instead. A the protocol level you just care about
finding a service, such as "http at www.irtf.org."

5. Connection-oriented protocol (COP) - replaces TCP. Handles error
correction and LOC changes. API is: listen(servicename) and
connect(servicename), send, receive

6. Connection-less protocol (CLeP) - replaces UDP. API is
listen(servicename), open(servicename), send and receive. Open just
establishes a send/recv binding on the local machine; it doesn't
generate any network traffic.

Comments? Criticism? Any other big block components of a
hostname-oriented protocol stack? Should any of these blocks be broken
up differently?

-Bill

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Christian Vogt <[email-masked]>
Date: Tue, 18 Nov 2008 15:03:58 -0600

Bill,

I like your breakdown.  Just note that it looks a bit like we would
re-design the entire Internet. :-)  In fact, the changes incurred by a
hostname-oriented host stack architecture are more moderate.  They do
not affect routing, addressing, or name resolution.  Only the host stack
and applications will change in backwards-compatible manner.

- Christian

---

From: Paul Francis <[email-masked]>
Date: Wed, 19 Nov 2008 13:36:33 -0500

I've long been very fond of the idea of making the name more of a first-class
object in the architecture.

I once did a hostname-oriented stack design called IPNL ("IP Next Layer"),
which was published in Sigcomm 2001.
http://www.cs.cornell.edu/people/francis/p6-francis.pdf (Sorry if this has
already been mentioned on the list and I missed it.)  It used a shim header
above IPv4 that carried host and "realm" fields, and an optional DNS name.
Intra-site routing protocols were supposed to be able to route on the name,
and legacy DNS would be used to route the name across the core.  The realm
and host fields would be filled in as the first packet made its way through
the internet, and subsequent packets would drop the name from the header.

I also still like the idea of coupling signalling (like SIP) and routing, and
in fact briefly had an IRTF group (end-middle-end) looking at this.  See the
NUTSS work
http://www.cs.cornell.edu/people/francis/sigcomm07-nutss-final.pdf.

PF

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christian Vogt
> Sent: Tuesday, November 18, 2008 4:04 PM
> To: William Herrin
> Cc: Routing Research Group Mailing List
> Subject: Re: [rrg] hostname oriented stack
> 
> Bill,
> 
> I like your breakdown.  Just note that it looks a bit like we 
> would re-design the entire Internet. :-)  In fact, the 
> changes incurred by a hostname-oriented host stack 
> architecture are more moderate.  They do not affect routing, 
> addressing, or name resolution.  Only the host stack and 
> applications will change in backwards-compatible manner.
> 
> - Christian
> 
> 
>