[IP] more on A return to the Intelligent Network
Begin forwarded message:
From: Karl Auerbach <karl@xxxxxxxxxxxx>
Date: December 4, 2005 3:34:37 PM EST
To: DV Henkel-Wallace <gumby@xxxxxxxxxxxxxxxxxx>, David Farber
<dave@xxxxxxxxxx>
Subject: Re: [IP] A return to the Intelligent Network
Reply-To: Karl Auerbach <karl@xxxxxxxxxxxx>
A while back I was one of the principal researchers on what we called
"smart" networking. This was DARPA/University of California stuff,
so what we intended was not wrapped in layers of proprietary
restrictions. It was quite unlike what the article describes.
I never got very far for non-technical reason that this was done
during the time I was on the ICANN board of directors - a job that
took 60+ hours a week, not leaving enough live brain cells to do this
research work.
What we were doing was trying to retain the basic idea of
connectionless routing of packets but adding some hooks into the
control plane.
We started with a modelling system, or rather a set of such systems.
These models were intended to have knowledge of the network topology
and other kinds of resources and constraints.
The primary input to the models would be "service level agreements",
which was somewhat of a misnomer because these would not be the heavy
things that we think of as SLAs, but could be things as simple as
someone picking up a VOIP phone and placing a call or requesting an
on-demand movie over the net.
The models would crank and produce a provisioning regime - what this
was could be and MPLS path (and perhaps a backup path) or into a goal-
directed mechanism in the routers. Rather than tweeking a bunch of
queing parameters the goal-directed mechanisms would be given goals
and constraints; the routers would be allowed to self-adapt. (The
goal-direction was not in the fast path; I was hoping to use a JVM in
the routers for the computation environment; were I do do it today
I'd probably go for Python.)
If the router couldn't meet the goals it would generate an exception
back to the modeling system. If the models couldn't account for the
inability to reach the goals then the exception would propagate to a
troubleshooting engine (which was really my favorite part as I've
always been interested in tools and methods to make our networks more
readily repairable. [My grandfather was a radio repairman; my father
a TV repairman; so I have a lot of sympathy for folks who have to fix
broken electronic systems.])
These mechanisms did not embed application smarts into the network;
they worked on flows. In IPv4 this means dealing with source/
destination addresses and ports and the QoS bits. In IPv6 we have
the additional flow identifiers.
As I said, my ICANN role kinda derailed my role in this.
I however, *have* worked, around 1994, on the idea of application-
layer routers. I called the idea "content routing" and I'd have to
scrounge deep into my ancient notes to get the details, but the
general idea was to reposition internet "content" - which turned to
to be what companies like Akamai did - but also to move it around
using chunks of content as if they were giant packets (not at the IP
layer of course) much like we did at Interactive Systems in the
1970's, or how Sendmail forwards (and relays) mail, or IBM's old
SNADS did it.
By-the-way, out of all of these things I have come strongly to
believe that the internet is in need of a "session" layer on top of
TCP. We really ought to revive the old OSI session layer, strip out
all the nonesense and cruft, and create a simple way to mark streams
with "resume" points. (Protocol engines need not retain stream
state.) This would greatly simplify mobility and content transfers.
--karl--
-------------------------------------
You are subscribed as roessler@xxxxxxxxxxxxxxxxxx
To manage your subscription, go to
http://v2.listbox.com/member/?listname=ip
Archives at: http://www.interesting-people.org/archives/interesting-people/