-----BEGIN PGP SIGNED MESSAGE-----
Hello RRG list readers -
This really has nothing to do with http://www.clock.org/~smd/catnip-dream.mp3
which was by Shonen Knife.
I had a dream a few weeks ago about the UUCP Mapping Project, being
accelerated enough that it could be used as an IP routing system.
(Think of uux as invoking a "forward packet" command rather than
rmail (forward mail) or rnews (forward news)... find a UNIX machine
and man uux).
I've been putting off describing this widely, because it was a long
dream, and because I've been busy/RSIed with respect to typing it up.
However, I feel "shamed" into offering a terse and incomplete overview
of what was described to me in the dream, for discussion.
In my defence, I should say that I did mention it a while ago on
the Internet's true architecture mailing list, IPv6-Haters...
Sean.
- - --
Two pieces: routing system and forwarding system
First piece first.
UUCP-style map distribution of Internet routing state
[from a strange CATNIP-influenced dream (dancing RFC 1707 demons),
and also see for example
http://www.sbay.org/sbay.map.guide.html
if you have never done UUCP maps before]
"Networks" (see way below) circulate UUCP-style maps, which can be
represented/approximated in ASCII like below.
We add an always-increasing date/sequence/generation for
each particular map, and we steal "#Q" for type-of-service/qos-info/etc.
- --- begin PGP signed message ---
#N partannet
#...
#Q best-efforts
#D date/sequence
partannet mfnnet(DIRECT), digex(DIRECT/2)
- --- end PGP signed message ---
- --- begin PGP signed message ---
#N partannet
#...
#Q diff-serv-code-point-xyz
#D date/sequence
partannet mfnnet(DIRECT), digex(DEAD)
- --- end PGP signed message ---
distribution: equivalent to "news.uucp.maps.usa.md" newsgroup
we can do this many ways, simultaneously
-- a multicast group?
-- something "in band"/"ad hoc" a la BGP
-- come and fetch?
-- send-tape-via-fedex?
-- actually _use_ USENET?
listeners tune into whichever group(s) they want.
listeners do not have to follow all maps.
do maps with different #Q go into different hierarchies?
"best-efforts.news.uucp.maps...", "low-latency.news.uucp.maps..."
versus
"news.uucp.maps.usa.md.best-efforts", "news.uucp.maps.usa.md.low-latency"
unless we are using NNTP/USENET specifically to distribute
maps, we can invent our own naming scheme.
how frequently adjacency metrics are updated is a function
of the distribution protocol(s) and local policy.
information hiding:
PGP signature can also be PGP sign+encrypt, so
that only certain people can see certain maps;
e.g., partannet has a secret connection he wants
some "default" or "rewriter" to know this stuff
to optimize his connectivity.
- - --
at intervals listeners will do a dijkstra SPF on the
collection of maps they are individually interested in,
including any of their own private maps they may have generated
pathalias -Tbest-efforts localnode
results in a complete source-route per known destination,
and a (set of) default network(s).
we want to "fix" pathalias:
authorization stuff, to make sure that declared
adjacencies are OKAY (e.g. a cookie signed by mfnnet
that needs to be in any map that declares an adjacency to mfnnet)
dealing with "ties" better -- multiple equal-cost paths
- - -
complete source routes:
foo!bar!uunet!digex!partannet!ipv4-address
but
if #T (diff-serv-equivalent-bits) is not best-efforts,
this cannot be used
this can be, though:
foo!bar!uunet!mfnnet!partannet!ipv4-address
this was calculated by pathalias -Tdiff-serv-code-point-xyz localnode
we can also specify partial source-routes
foo!bar!uunet!partannet!ipv4-address
foo!bar!partannet!ipv4-address
we may choose to do this deliberately, because we don't
want to keep up with all the maps, to avoid dijkstra far away
rewriting "complete" source-routes? this was useful (and controversial)
in UUCP
ipv4-address is REPRESENTATIVE. this could be an
ipv6-address, an ipx address, a DNS name, you name it.
- - --
What's a "network"? An abstract collection of routers
with the same forwarding policy towards the rest of the
world.
A UUCP node was either a single machine, or a collection
of machines which behaved so identically the rest of the
pathalias-using world would never know.
partannet is a network with several IPv4-talking routers
and machines
it could run other things (ipx, ipv6, DNS names), in which
case "partannet!%s" (%s in printf sense) needs to be
routable by the exterior routers in the partannet domain,
and whatever 'native frame format(s)' are in use must
be a border/translator/whatnot a la CATNIP (see below)
- - --
fine-tuning:
in UUCP maps we were stuck with ~~ 2-10 character
(ASCII alnum + a few chars)
BGP was stuck with 16-bit binary fixnums
both are globally unique values
we can have a bigger flat/globally-unique namespace, but
also we can be hierarchical
foo.bar.partannet -> partannet!foo!bar
*but*
these are completely relative to the globally unique
partannet, and MAY NOT BE REWRITTEN THIS WAY (except by partannet)
because "foo" and "bar" are not globally unique #N names
so
nodeA!nodeB!east-coast.usa.uunet!somenet!%s
is not identical to
nodeA!nodeB!uunet!somenet!%s
but may in practice have the same semantics, or not:
because of defaulting principle, nodeB in first case
may know something special about reaching east-coast.usa.uunet
and may do something different from just uunet (or *.uunet)
hierarchical names are rooted on a globally-unique #N
nodename
- - --
what's the %s?
ideally we don't CARE how endpoints are identified
we want to give some space for NSRG thinking and the
like and for both future change and simultaneous operation
this matches the CATNIP architecture
personally, i favour it being a DNS-searchable
representation of a host+port, since this should be
portable through ANY routing domain, ipv4 or otherwise
that is, at a "sean's mutant catnip" border (in this
case the #N called partannet), a DNS lookup is done _on
the IPv4 side_ (the "inside" in NAT speak), to find an
appropriate set of addresses to put inside the IPv4
destination-related bits
packet arrives for partannet!andrewspc.partan.com+tcp+smtp
a set of DNS lookups result in 10.0.0.2, 6, 25
this will go into the IP header + TCP pseudoheader
on the destination side
the source on the "outside" is
mfnnet!sprintlink!ebonenet!dorannet!seanspc.doran.dk+tcp+20001
and the gateway will write this into some appropriate
IPv4 info for the IP header + TCP pseudoheader
such that the source IPv4 address looks like the
gateway (so that IPv4 routers can deliver reply traffic)
it will ALSO ensure that a DNS mapping for this
address works right in some way (e.g., 10.0.0.1, 6, 20001
results in PTR RR type things for seanspc.doran.dk+tcp+smtp-sender
and that the A RR etc queries result in 10.0.0.1, 6, 20001)
gateways can be expected to consume a bunch of IPv4 addresses
in the local IPv4 routing domain
- - --
Forwarding system:
frame format RFC 1707's CATNIP line format is a simple
superset of some then-popular line formats. A straightforward
translation to and from the CATNIP format is a principal goal.
things have changed, and now we can have interesting
arguments about time-space tradeoffs in the header
processing. because of this, it is important to make sure
that we can have SEVERAL line-formats, instead of just one.
it is just important that no information is lost at
translation boundaries among various "sean's catnip nightmare"
regions, and that there is two-way translation between line
format and the output of a reference pathalias equivalent.
possibilities:
- carry actual ASCII paths in
variable-length fields
- compress the ASCII paths into some fixed-size field
- compress/map/indirect/shared-LZW-symbolify into some smaller
fixed-sized field
obvious target: 8 bytes (GSE field of 8+8)
- - --
Can we optimize the %s piece, or should we make it a globally opaque
identifier, which can be translated ONLY by the final #N
(or sub-#N if the last network in the path is hierarchically encoded)?
Yes: if NSRG gives us a global namespace in which we can
find universally useful endpoints, independent of the
location from which we do a lookup.
the namespace is likely to resemble DNS names
thus, if we have a globally unique name like
"andrewspc.partan.com+tcp+smtp" we have a "what"
from which we can get a "where" that ends with "...!partannet!%s"
the "..." part can be shortcutted (see rewriting complete source routes)
this shortcutting makes compressing ASCII paths into
A small field easier, and again was done in UUCP
days; however, this loses information if a complete
source route was specified
note again that the #Ns are globally unique, so a
complete source route need not be specified; we can
do hop-by-hop forwarding ("defaulting" through immediate
neighbours, mentioned above), and keep information
out of the packet headers!
That is, I think we can use 8+8 as an experimental
platform; the first 8 bytes (GSE) are the last #N node
before the %s. Because %s is anchored in only one #N
node, namely the last one, this is OKAY.
Nice side effect, first arrived at by Peter Lothberg: we
can put the %s piece in the 2nd 8 bytes of 8+8.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQCVAwUBOjgWo6/czfWiyH41AQHybQQAjMVhCYiIWYUlaPDGe6zKu0fpfF57coVy
IziyAI+2uBiNOa9BhaGA5rieb2o9j4Ymo74/nrSaSKlj2U2bBPlv+H/QgAIX2X1Y
HhhSyUYv0+rces2keI8htb1Pzrrn2abDkFm+/EiVJMlfv2dRdnQC3Kudr5AoNb7x
xTQseBAGaHs=
=dcEd
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT