Subject: A tunneling proposal

From: Ramakrishna Gummadi <[email-masked]>
Date: Sun, 15 Jul 2001 20:58:15 -0700 (PDT)

Hi all,
I have been thinking about the following approach that might be useful
towards solving the multihoming problem. It does not require changes
to end hosts, and can be used together with provider independent
addressing.

The basic idea is to have a mechanism that can dynamically create
stateless tunnels within the transit providers of a multihomed enterprise
to route around failures so that existing connections can fail over
to the new paths. For example, in the figure below, suppose host B uses
hostA's address drawn from ISPB's address space for a connection. Now, if
there is a connectivity problem from ISPB to the site, router RA can
initiate a tunnel between ISPB and ISPA so that packets from hostB (or
any other host trying to reach the multihomed site) are IP-IP encapsulated
and forwarded to RA. Traffic exiting the site that uses the failed address
can likewise be internally routed to RA, from which point RA injects the
packets into ISPB's network using the tunnel.

			hostB
			|
  ______________________|____________________
 |                                   	     |
 |                    Internet               |
 |___________________________________________|
       |                             |
       |                             |
     +----+                        +----+
     |ISPA|   tunnel               |ISPB|
     | 	  |----------------------- | 	|
     +----+----------------------  +----+
        |                            |
  link1 |                            | link2
      __|___________________________ |___
     |   RA                         RB   |
     |   |                           |   |
     |  -------------------------------  |
     |                 |                 |
     |               hostA               |
     |        PrefA:Prefsite:hostA       |
     |        PrefB:Prefsite:hostA       |
     |                                   |
     |___________________________________|

This scheme works with existing protocols like TCP and UDP that can only
use one address per connection. The only failure made that this can not
tolerate is when an outage occurs between hostB's service provider and
ISPB, but that does not affect the site's ability to talk to the rest of
the world using ISPB. I think this problem is more of hostB's than the
site's, both because this problem is localized, exists in the current
Internet, and can be made to go away with protocols like SCTP.

I also think that this architecture more or less meets the requirements
desribed in the multi6 requirements draft. I am sure proposals like
this have been floated around in other contexts, but have no references to
make any comparisons.

The tunnel creation should be done carefully, but I think it can be
managed securely because it is always initiated by one of the site's
routers, and the operation is restricted to the site's providers. Thus,
any trust can be statically established and maintained. Also, the tunnel
is only created upon a failure, and is scalable because there is no
per-flow state required.

Any comments are welcome.

thanks,
ramki

------- end of forwarded message -------

---

From: [email-masked]
Date: Mon, 16 Jul 2001 13:01:22 +0900

>to end hosts, and can be used together with provider independent

	I guess your idea is very similar to RFC2260 as well as
	draft-ietf-ipngwg-ipv6-2260-02.txt.  these RFC/draft do not have
	any "dynamic" tunnel establishment, but the end goal is very similar.

itojun

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Sun, 15 Jul 2001 21:48:51 -0700 (PDT)

Thanks, Itojun. I think the difference between the proposals described in
these rfc/drafts and my outline is that the tunnel is created
(statically or dynamically) directly between the ISPs, without requiring
multiple physical links from each of the site's border routers
to each of the ISPs.
That is, upon receiving a request from the site's border router peering
with ISPA, ISPA sets up a traffic tunnel from itself to ISPB for carrying
ISPB's traffic at an appropriate peering point.

 Apart from saving on the extra physical links, this can
potentially
provide more robustness because one can overcome more failure modes: for
example, what happens when the (single, say) ISPB's border router peering
with each of the site's border routers (albeit across multiple
physical links) goes down? In my outline, because
ISPA and ISPB potentially peer at multiple points, these kind of failures
can be tolerated. Also, there is a possibility of performance optimization
for ISPA (after all, he is carrying extra traffic) because ISPA can choose
the optimal exit point (from its perspective) into ISPB.

This may complicate things, but I guess there is a possibility that the
benefits may well make the complexity worthwhile.

thanks,
ramki

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 16 Jul 2001 10:13:45 +0200 (West-Europa (zomertijd))

On Sun, 15 Jul 2001, Ramakrishna Gummadi wrote:

> to the new paths.

Why would you need to do this? If you can send tunneled packets to the
destination network, I can see no reason you can't send un-tunneled packets
too.

Iljitsch van Beijnum

---

From: Tony Li <[email-masked]>
Date: Mon, 16 Jul 2001 01:18:29 -0700

| > The basic idea is to have a mechanism that can dynamically create
 | > stateless tunnels within the transit providers of a multihomed enterprise
 | > to route around failures so that existing connections can fail over
 | > to the new paths.
 | 
 | Why would you need to do this? If you can send tunneled packets to the
 | destination network, I can see no reason you can't send un-tunneled packets
 | too.

Routing.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 16 Jul 2001 10:33:50 +0200 (West-Europa (zomertijd))

> Routing.

I didn't read the original message carefully enough, my apologies.

I took "around the failures" to mean from one point within an ISP to another
point with the same/a different ISP.

Tunnels can fix some types of failures, but they can't fix every type of
failure, like routing problems that affect the entire ISP. This kind of
multihoming is clearly inferior to the regular IPv4 way.