[e2e] node addresses vs. interface addresses

Christian Huitema huitema at windows.microsoft.com
Thu Aug 1 09:09:07 PDT 2002


> From: Joe Touch [mailto:touch at ISI.EDU] 
> 
> J. Noel Chiappa wrote:
> >     > From: "Tim Moors" <t.moors at unsw.edu.au>
> > 
> >     > Perlman explains how "internal network numbers" in 
> IPX helped avoid
> >     > sub-optimal routes to multihomed destinations
> > 
> > Except that this is a bad idea in a very large network. In 
> short, it's
> > putting the entire cost of multi-homing (one rarely gets a 
> benefit without
> > some cost somewhere, neh?) into the routing, where the cost 
> is paid by
> > everyone (effectively - long arcane routing point elided) 
> across the network,
> > to maintain a route to that destination. This is fine in a 
> small network,
> > where the total incremental cost is small, but not fine in 
> a big one.
> 
> Except again that this can be hidden from the rest of the 
> network using 
> tunnels. A host can have a single endpoint address - on an "internal" 
> virtual interface, used through a set of tunnels, each using outer 
> addresses based on one of multiple real interfaces.

You can hide it somewhat, but Noel draw the fundamental tension. The
distributed routing systems maintains route to separate end-point. This
computation is easiest when the structure of end point "addresses" is
closest to the network topology. The hierarchical structure of addresses
works best on a tree-like topology. All deviations away from the tree
topology are costly. We know we must have some deviations: we certainly
don't want to have the topology centered on a big hunking
interconnection point, so we must maintain what is essentially flat
routing between the large backbones in the "default free zone"; this has
a cost, that scales as at least O(N.log N) with the number of objects in
this zone.

Having single addresses for multihomed machine essentially distorts the
tree: you take two leaves that hang from different limbs and glue them
together. This implies additional computation all the way to where the
limbs are joined. As Noel said, this may be OK in a small network, i.e.
if the limbs are joining close from the multihomed host and far from the
root; but even a O(N.logN) function means you don't want to bring too
many of those leaves in the "default free zone".

The alternative to loading everybody with the problem is to shift the
load to the multihomed host and its peers. There are many ways to do
that -- naming systems, tunnels, dynamic redirection. All these
alternatives are enabled by "per interface" addressing, since this
precise addressing allows the peer to choose the path over which a
particular packet will be sent.

-- Christian Huitema




More information about the end2end-interest mailing list