some more transport MH ideas...

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

I wanted to do this more formally by putting together a draft, but I'd like to
run the ideas before everyone first.

There is an important feature of strongly aggregated networks that I think is
being ignored.  If a path to a particular point of the aggregation tree is
unreachable, it is highly likely that other addresses to that branch of the
tree are unreachable too.  This can provide hints to the address selection
mechanisms to list addresses with prefixes for that branch to have lower
priority in the selection process.

If the aggregated structure of such an internet can be relied upon, I believe
that through the use of what I coin "reachability trees", one can resolve some
of the criticisms of transport layer multihoming has when it comes to address
list explosion as such trees might be reasonably more compressible when
exchanging address information and also lead to efficiencies in TCP stack
design.

To find forward reachability information, one would probably need to retain
somewhere locally a "reachability cache" which contained many such reachability
trees.  Such a cache could live on the host itself, or could be operated in a
similar manner to a DNS server or a router's routing table.  The information in
such a cache is likely to much more volatile than DNS though and less complete
than a routing table.  Personally, I think that each node should manage its own
cache as it would have much finer control over the validity of the data in such
a cache, and also a host is likely to have localized information for it's
current connections.

One could exchange information between nodes as there is likely to be
reasonable correlation between host caches like there is in DNS, but there is
then a difficulty with issues of security.  If addresses are still exchanged
between end points, spoofing is eliminated.  It just leaves the issue of denial
of service.  If we used the 1 hop rule as in ND, this could be managed in a
reasonable manner within a local network environment.   Important network
events could also be multicast by routers to expedite cache updating.

Please note that while this sounds very similar to a routing tree, in practice
it might be managed somewhat differently.  It also sounds a bit like ARP for
the wider internet.

Peter

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210