Re: A tunneling proposal

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

> >As for backpatcing TCP to work with multihoming, this would
> >not work with the current apps, and socket API if done the SCTP
> >way---SCTP requires the apps to *explicitly* give a list of addresses
> >to use on a connection. To backpatch TCP to do the same would mean
> >requiring the TCP layer itself to figure out what additional addresses
> >it can use *without* the app knowledge. This means that the protocol
> >stack can get it wrong if there is address translation going on
> >for getting provider independence, etc...
> >Ultimately, it will basically look like GxSE...
>
>
> The problem is that multi-homing may be a number of AS's away. i.e. the
> local AS may single-home to an upstream AS which in turn may multi-home to
> a number of AS's via peering connections, multiple upstreams, etc. How then
> does the local TCP session  understand the situation if the upstream AS is
> doing multi-homing via dynamic translation of the routing goop part of the
> end point's address?
>

In SCTP, it is the job of the app to be feed the transport with a list of
correct globally routable destination addresses, and be prepared to
receive error notifications after an address fails. This is different
than the GxSE's behavior of making the destination advertise the addresses
where it can be reached.

As for GxSE's behavior in the multi-level multihoming scenario,
I think Paul is probably the best person to
answer this, as I am not certain how the site border router knows to
signal the upstream provider's router to attach the address-list extension
header.

As far as tunneling is concerned, although not strictly related to
multihoming per se, one can use address translation (or goop rewriting) to
get provider independence. In this multi-level multihomed case, this
translation would work as follows.

Consider the following concrete scenario, to ease explaining things a
bit:
                                 D
                                 |
                           +-----+-----+
                           |  Internet |
                           +---+----+--+
                              |      |
                             |        ||
                            |           |
                        //-+\\   L5  //--+-\\
                       |  ISP ******* ISP2   |
                       |  1   |      * --+-//
                        \\-+/|     **   |
                             |   **L2   | L3
                          L4 | **     /++
                       +--+---*      |    \
                       |    R2|+-----+R1  |<--Multihomed Enterprise E
                       |ISP3  |       \-+/
                       +------+  L1     |
                                        S

Assume that E multihomes via ISP3 and ISP2, whule ISP3 itself multihomes
via ISP1 and ISP2. Further, assume that both ISP3 and E use PI addresses,
and border exit routers R2 and R1 respectively rewrite the source
addresses on outgoing packets, and destination addresses on incoming
packets. Destination D will correctly see a globally routable address for
source S even after the packet uses R1-L1-R2-L4-ISP1-(Internet)-D, while
reverse packets correctly reach S with the PI address set by E. Thus, S
does not need to know a globally routable address as part of the ISP3
prefix space (it may still have a globally routable address from ISP2
prefix space to use for traffic via S-L3-ISP2-(Internet)).

If ISP2 has problems, and links L3 become unusable, R1 tries to setup a
tunnel to ISP2 using a globally routable address in ISP2 via ISP3 so that
existing connections can survive. Note that ISP3 does not have to setup a
tunnel himself---when R1 requests a tunnel setup, since L2 is assumed to
have become useless, he has no other way than use L4-ISP1-ISP2 as the path
on which to forward the tunnel setup request as well as further tunnel
traffic. ISP2 knows the globally routable address of R1 because ISP3 would
have translated it to become a globally routable one, and now ISP2 would
use L5-ISP1-L4-L1 as the tunnel path for traffic that was previously
using D-Internet-ISP2-L3-E-S. Thus, nothing short of a complete outage
within ISP2 should hamper traffic flow.

The sticky question seems to be whether it is acceptable for R1 to request
ISP3 to trigger a global BGP announcement for the site's address prefix
drawn from ISP2 so that traffic can be forwarded via
(Internet)-ISP1-L4-ISP3-L1 directly instead of a tunnel. I don't know what
bad things happen in this case.

Of course, the unworked out part in the above is how R1 knows a valid
address in ISP2 that can be used as the other tunnel endpoint.

thanks,
ramki