[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A tunneling proposal
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 -------