Re: roadmap

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Mon, 24 Feb 2003, Kurt Erik Lindqvist wrote:

> >   "One way of achieving multihoming that exists already today is to use
> >    multiple addresses on the end hosts."

> > This doesn't work so it shouldn't be presented in this way. Also, for
> > future multihoming solutions it is important to know how having
> > multiple addresses is handled; there are many different ways.

> Send text! :)

Don't think I won't! I have to do some programming work so I was looking
for a way to procrastinate anyway...

Here is some text. The trouble is that it doesn't fit into your
classification, and I see no way to make this happen.

A way to make multihoming very scalable without taxing the routing
system is to use address space from each ISP the multihomed network is
connected to, rather than (semi-)independent address space. This allows
for full scale provider-based aggregation and full scale multihoming
benefits at the same time. There are basically four ways to accomplish
this:

1. Multi-address aware applications. These exist today. The DNS and
email both take several destination addresses for many operations and
cycle through them one by one until a working address is found. This is
traditionally used to fall back from one host to another, but this
mechanism is also usable for falling back from one address to another
address tied to the same host. However, this mechanism doesn't provide
any way to switch from one address to another during a session. This
makes it unusable for applications with long-lived sessions. But for
applications that typically use short transactions which can simply be
repeated after failure, this mechanism can work very well. One
application that uses short transactions most of the time is the world
wide web.

2. Multi-address aware transport protocols. At this time, there is SCTP.
There are several proof-of-concept modifications to TCP to accomplish
the same thing. This could probably be more interoperable than switching
to a new transport protocol.

3. Failure repair with tunnels or extension headers. It has been
observed that Mobile IP offers functionality that can be used here,
although there are also elements missing that would be required for a
usable multihoming solution based on MIP.

4. Two-space systems, where there are addresses (or names that don't
look like addresses) used for the identifaction of the endpoints taking
part in the communication and different addresses used to route packets.
Solutions that separate the identifier and locator functions marry
portable address space to full aggregation within the routing system.
There must always be a locator as the destination address (for
forwarding) and a locator as the source address (so ICMP messages can be
sent back) in each packet. The identifiers may be carried explicitly or
they may be implied and be found by looking up the locators and possibly
session-identifying information in a mapping table. However, as explicit
identifiers aren't protected by even the low level of security provided
by return routability, it is impossible to use them they way they are
found in a packet. Rather than trying to authenticate the identifier in
the packet and incur even more per-packet overhead, it seems logical to
use implicit identifiers.

Mechanisms 1 and 2 (mostly) can simply use the DNS to find additional
addresses. Mechanism 4 and maybe 3 as well need a more extensive mapping
or negotiation mechanism to discover all the information needed to
operate. Another difference between 1 and 2 on the one hand and 3 and 4
on the other hand is that it may be possible to implement 3 and/or 4 on
a proxy multihoming processing box. This could have important deployment
advantages.

Iljitsch