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 PROTECTED] [mailto:[EMAIL PROTECTED] 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
>
>
>
> On Nov 17, 2008, William Herrin wrote:
>
> > 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
>
>
>
>
> _______________________________________________
> rrg mailing list
> [email protected]
> https://www.irtf.org/mailman/listinfo/rrg
>
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
