Re: [Lksctp-developers] Multihoming in LKSCTP (resent)

[La M. H.P. Y. <pi...@em...>]

Sridhar Samudrala writes:
 > On Wed, 18 Dec 2002, La Monte H.P. Yarroll wrote:
 > 
 > > Sridhar Samudrala writes:
 > >  > On Wed, 18 Dec 2002, Jon Grimm wrote:
 > >  > 
 > >  > > Some random comments.
 > >  > > > Hmm...  I THINK that this algorithm will never fail over to an
 > >  > > > alternate route for a given destination address.  It depends on what
 > >  > > > "valid" means for a route.  If a route is marked as "invalid" when
 > >  > > > SCTP decides it is unreachable, then redundant routes to the same
 > >  > > > destination will get used.
 > >  > > > 
 > >  > > > The change I was suggesting would essentially replicate the transport
 > >  > > > structure for each route to a given destination.  It does mean we need
 > >  > > > a separate shared congestion information structure for each
 > >  > > > destination address.  Do we get that for free with a struct dst?
 > >  > > > 
 > >  > > > > I hope the following picture shows the configuration that La Monte suggested.
 > >  > > > 
 > >  > > > Nice artwork!  Yes, that's exactly what I meant.  I added interface
 > >  > > > names just in case.
 > >  > > > 
 > >  > > > >    +--------------+         +--------------+          +---------------+
 > >  > > > >    | Machine  A   |eth0  f1 |  Router      |          | Machine  B    |
 > >  > > > >    |10.241.245.1  +---------+ 10.241.245.10|     eth0 |               |
 > >  > > > >    |              |eth1     |              |    +-----+ 10.241.244.3  |
 > >  > > > >    |10.241.244.1  +----+    |              |    |     |               |
 > >  > > > >    |              |    |    | 10.241.244.10|    |     |               |
 > >  > > > >    +--------------+    |    +------+-------+    |     +---------------+
 > >  > > > >                        |           | f2         |
 > >  > > > >                        |           |            |
 > >  > > > >                        +-----------+------------+
 > >  > > > >
 > >  > > > > Let us see how the above algorithm works with the above setup.
 > >  > > > >
 > >  > > > > When both the interfaces are up on Machine A, the following route is
 > >  > > > > cached in the transport (src:10.241.244.1, dst:10.241.244.3) and all
 > >  > > > > the packets go through 10.241.244.1.
 > >  > > > >
 > >  > > > > When 10.241.244.1 is brought down, the cached route entry will be
 > >  > > > > become obsolete and a new route entry is requested for 10.241.244.3
 > >  > > > > which should return (src:10.241.245.1, dst:10.241.245.10). This will
 > >  > > > > cause the packets to go through 10.241.245.1.
 > >  > > > 
 > >  > > > Does Machine A have two static routes to 10.241.244.3 with different
 > >  > > > metrics?  What subsystem makes the cached route entry obsolete?
 > >  > 
 > >  > The route to Machine B via eth1 will be automatically created when the interface
 > >  > comes up. 
 > >  > But we need to setup a static route to 10.241.244.3 via eth0 with 10.241.245.10
 > >  > as the gateway.
 > >  > The routing subsystem makes the cached entry obsolete when the interface goes
 > >  > down.
 > > 
 > > Ah!  But if the router goes down and SCTP decides that the route
 > > through eth0 is unreachable, nothing changes in the routing tables,
 > > and we do not fail over.
 > 
 > Yes. In that situation, we cannot depend on the routing layer to provide us the
 > information about a path failure so that we can switch routes. 
 > But, we can try to get a new route entry with an alternate source address(eth1)
 > when we start seeing path error count to increase caused by T3-rtx timer and
 > heartbeat timer expirations.
 > Do you agree with this solution? Or is there a better one? 

There is a better one.

For each destination we should collect EVERY valid unique route in the
local table.  Valid means that the associated source address is bound
to the socket.  Unique means that (interface, next hop) is different.

We then create a separate transport structure for each of those routes
and then use the existing failover mechanism.

The catch is that the congestion information needs to move to a
separate structure which can be shared among multiple transport
address structures with the same destination address.

 > Thanks
 > Sridhar