Re: Transport level multihoming

[Ramakrishna Gummadi <ramki@cs.berkeley.edu>]

On Wed, 8 Aug 2001, Peter Tattam wrote:

> On Tue, 7 Aug 2001, Ramakrishna Gummadi wrote:
>
> > > Doesn't similar constraints apply to any transport level solution ?
> > > I am not sure how a transport solution works when one of the
> > > upstream ISP's link fails. Isn't this one of the requirements ?
> >
> > I don't think that an end-host level solution without address
> > translation can work effectively
> > in a decentralized multi-tier multihoming scenario because the end-hosts'
> > addresses have to be added/deleted/modified whenever a provider
> > adds/deletes/changes its providers. Address translation has to be used,
> > but this will be rendered less effective in the
> > transport level multihoming case because end-hosts will now have to be
> > aware of the final routable addresses so that they can advertise them in
> > the payload, assuming we don't want to change every app at the other
> > end-point to make it aware of multiple addresses.
> >
>
> I thought that site renumbering was supposed to deal with this?  Bob Hinden had
> a lot to say on the issue.

I think the mechanisms in IPv6 are adequate for sites/hosts that use one
address per connection. I don't think they would be adequate if we
consider multi-tier multi-homed scenarios that carry all possible
addresses in packets.

I may be wrong, but this clearly seems to be the case in any
transport-level multihoming solution...

>
> > A tunneling (or any network-layer)+translation based solution would not
> > have this problem.
> >
> > Another problem with the transport-level multihoming is that
> > the number of failure modes in multi-tier multihoming are decreased. For
> > example, consider the scenario where a site is dually-multihomed, while
> > each of the providers are triply multihomed to three different providers
> > each. The question how many addresses do the hosts in the site have? If it
> > is two, then it means that the site can not tolerate failures in four of
> > the providers twice removed from it. If it is six, then it means we are
> > exposing the site to addressing issues not related to it.
> >
> > A tunneling+translation solution solves this problem cleanly by using only
> > two (or
> > as many addresses as there are providers) provider-independent addresses
> > to the site. The site's immediate providers would independently translate
> > the addresses to meet their own load-balancing needs without leaking the
> > site's prefixes. When a failure between the provider and its higher-up
> > is detected, by creating two tunnels between itself and the higher up via
> > the two working ISPs, a provider can ensure connection survivability and
> > can even load-balance failed traffic among the working providers. The
> > tunnels are only one "leve" deep, and are transparent to all others,
> > including the original site.
> >
> >
> > thanks,
> > ramki
> >
>
> Won't a translation solution have the risk of translator box meltdown?  i.e.
> may not scale?

It is only for the customer's prefixes that a provider has to make
translation. The translation can reside in the customer's border router,
and needs to contain only entry per site. Secondly, translation is
entirely optional. Finally, I think stateless (with regard to
packets) translation is not very expensive---already, web switches provide
hardware layer-7 (looking at cookies and urls) "virtual ip" services for
load-balancing and failover, so a layer 3 translation certainly looks
certainaly possible to me.

thanks,
ramki

>
>
> 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
>
>
>