RE: Hello everybody

[Dan Williams <dcbw redhat com>]

On Mon, 2005-02-14 at 16:36 +0000, Rui Campos wrote:
> Hi Dan,
> 
> Thanks for your quick answers!
> 
> I am wondering whether "Network Manager" could manage such a switch in a
> transparent way for the applications. Anyway, you already answered this
> question in our comprehensive explanation. Thanks for that! 

Without something like Mobile-IP, I think it's impossible not to break
existing IP connections.  Instead, we need to make applications aware of
the network events that NM broadcasts, like "network now up" and
"network now down".  In the gaim example, when gaim receives the "down"
signal, it should disconnect its connections, and wait for the "up"
signal.  If it receives that signal within, say, 10 seconds, it should
reconnect the connections that were broken by the "down" event.  If not,
perhaps it should display the "You were disconnected" dialog.  Its a
hard problem, because there is no guarantee how long the network will
stay "down".  The user may be searching for the correct WEP key or
passphrase, may be away from their desk when the passphrase dialog pops
up, or they may have traveled to an area where no network connection is
possible.  Applications have to take into account that the network does
not have to come back up immediately.  Really, they have to be anything
other than incompetent about network state, which is what they are now.

Evolution, for example, has online/offline modes, but it expects the
network to be available when you choose "offline", because it tells each
of its backends (IMAP, POP3, etc) to move to offline mode where each
backend may do something like cache mail.  That takes time.  In the NM
model, you don't have any time since the network has already gone away.

> In my PhD thesis (I just started four months ago :-)), I am looking for
> mobility and multihoming support in an integrated fashion, in a
> heterogeneous environment. The kind of mobility support I am interested in
> is similar to that provided by Mobile IP framework, i.e. changes in network
> access are transparent to transport and application layer.
> 
> P.S. By the way, have you ever considered some kind of synergy between
> Mobile IP and such a Network Manager?

I had talked about it with one of our other guys here quite a while
back.  I just went and read
http://www.computer.org/internet/v2n1/perkins.htm to brush up a bit.  It
appears that this would need both kernel-side and user-space-side
components.

First, on the kernel side, we need to ensure that the encapsulated
packets from the home agent are decapsulated correctly and delivered to
the upper layers of the TCP stack with the correct home IP address
intact.  That seems like a job of the network stack or of iptables,
which can rewrite packets depending on certain rules.  Of course, since
these rules would be dynamic, iptables might need modification.  But
certainly something on the kernel side needs it.

On the user-space side, where NM lives, we'd need a couple more things.
First, when we move to new networks, we would need to broadcast a
request for a new "care-of" address.  Once the reply was received, NM
would need to notify the kernel of the new care-of address so it could
rewrite the packets correctly.  NM would then need to ensure that the
care-of address works correctly, then notify the home-agent of the new
care-of address.  NM would then need to set up the IP-within-IP tunnel.
Once that is done, the network is more or less "up" and applications
could send and receive data with no interruption.

In an upcoming rewrite of NM (starting this spring), I hope to make the
NM architecture more modular to support more services and devices.  For
example, the Mobile-IP bits don't really need to be a core part of NM,
but could be a service that NM depends on and makes requests of.
Something like "Hi, Mobile-IP, please get a new care-of address and tell
me when you're done."  The mobile IP bits don't need to know which
network you're connecting to (ie wired, wireless, whatever), they just
need to know which particular network interface to start operating on.
NM doesn't need to know about the details of the Mobile-IP negotiations,
just when they either complete successfully, or fail, so that NM can
announce the network as "up" or switch the connection to something else.

As long as the kernel facilities are there to support Mobile-IP, the
packet encapsulation/decapsulation, and delivery of packets with the
correct "Home" IP address to the application layers, I think this isn't
a hard problem to solve.

Dan