Date: Sat, 28 Sep 2002 17:30:20 +0200 From: Marco Molteni <molter@tin.it> To: freebsd-mobile@freebsd.org Cc: freebsd-net@freebsd.org Subject: Fw: Link Triggers on Linux Message-ID: <20020928153021.6029.qmail@cobweb.example.org>
next in thread | raw e-mail | index | archive | help
FYI.
Very interesting for people working on mobility and wireless networks
like 802.11.
Anybody interested in doing something similar for FreeBSD?
Marco
----- Forwarded message from "Jean Tourrilhes" <jt@bougret.hpl.hp.com> -----
To: pilc@ietf.org
From: "Jean Tourrilhes" <jt@bougret.hpl.hp.com>
Subject: [pilc] On Link Triggers (implementation)
Date: Tue, 24 Sep 2002 15:57:29 -0700
Hi,
I quickly scanned through the Link Trigger discussion on the
mailing list (don't have time to read all that). Maybe I should add a
few comments (and sorry if I re-ignite a flame war).
I've recently wrote a little protocol call P-Handoff. It is
totally off topic, apart from the fact that to implement this
protocol, I needed Link Triggers, which of course I also implemented
(my bad habit of implementing before talking about it).
So, maybe my practical experience can be of some use to some
of you (or maybe not)...
1) Implementation status
------------------------
All implementation done on Linux only.
Implemented for Wireless LANs (802.11, ...) through the
Wireless Extensions (Wireless Events) since early 2002. Standard in
Linux kernel 2.4.20-pre2 and higher. Not all WLAN driver do support
it (See my web pages for more details).
Implemented for IrDA (IrNET) through the IrNET control channel
since early 2001. Standard in most 2.4.X kernel.
2) Mechanisms
-------------
I fully agree with few people, the mechansisms to deliver
those trigger are totally OS specific.
For example, under Linux I use the RtNetLink socket, which is
also used for most management messages (new/del routes, interface
up/down, ...). I expect that other OSes would have more appropriate
mechanisms.
I also use different mechanisms for different link layers, but
that's mostly an accident ;-)
3) Semantic
-----------
My personal belief is that the semantic of those events is
link specific, therefore I believe that it won't be possible to
standardise them across all link layers.
I'm not talking about the small stuff, such as the fact the
WLAN events carry a IEEE 48 bit address while IrDA events carry a
random 32 bit address. Most often the meaning of the event as well as
the action to take on it is different.
I guess I'll have to go through an example on that one ;-)
These are the "failure" events that I've defined and could be
used to trigger Vertical-Handoff.
WLAN events :
o SIOCGIWAP(addr) : Successfully registered to Access Point
with address 'addr'. If 'addr' is NULL, it means that we could not
find any Access Point suitable (out of range). This is generated at
the end of the link layer handoff.
o IWEVTXDROP(addr) : Packet sent to 'addr' was dropped due to
excessive retries.
o SNR : this is not an event, but you can poll the SNR for
each peer through iwspy (updated on Rx'd packets).
IrNET events :
o Disconnected(addr) : IrDA stack closed the link connection
to peer 'addr'. May be due to link failure (12s timeout) or explicit
disconnection from one end. At this point, the IP interface is going
to be destroyed.
o Link-Blocked(addr) : Peer 'addr' failed to turnaround the
link layer. We have not heard from the peer for one second (max link
turn around time in IrDA is 500ms). However, the connection to the
peer still has not timed out.
As you can see, the semantic of those events are very
different, and you really need to understand in which cisconstance
they are generated to make good use of them.
For example, if you want to trigger vertical handoff on the
"Link-Blocked" event on IrNET, you have to remember that you need to
explicitely disconnect the IrNET connection.
On the other hand, you may want to accumulate a few IWEVTXDROP
events before doing anything to avoid false positive due to long fade
on the wireless channel, especially if your number of link level retry
is small. For example, you may want to only start pre-allocating the
backup path on the first event, and to really switch only after 3 or 4
events. But, you also need a fallback to IWEVTXDROP, because it will
be generated only if there is outgoing traffic (as opposed to other
events that will be generated in absence of traffic).
And don't expect any SNR on IrDA ;-)
Yeah, you could probably defined some meta-events abstracting
and encapsulating the link layer events in some form (like "something
bad happen on the link"). Actually, nobody prevent you to define your
own set of standard events on the low level events I've defined.
But in that case you would loose the benefit of the approach,
which is to have a precise and dependable status of the link layer
(which is needed to know exactly what's happening).
4) Timing
---------
Those events don't have to be fast, but they have to be
precise. None of the events I've defined is really fast, apart from
IWEVTXDROP.
For example, SIOCGIWAP occur *after* L2 handover. Most L2
handover on 802.11b take in the order of one second. On the other
hand, the L2 state after this event is stable, and you don't run the
risk of having L2 handoff and vertical handoff happening in parallel.
Same for the IrNET events. By design, the link layer is not
going to give you anything faster than that. Most wireless links need
to average bad channel and fading on relatively slow time (order of 1
second) through the use of ARQ/FEC/interleaving/diversity, so you need
wait patiently while the link do its job.
I personally believe it's more important to make the decision
right than to make it fast.
5) Where do events go
---------------------
Some people have suggested that those events should go up the
IP stack. I personally don't think that this is the best approach,
because this is not where those events are needed. And also I don't
want to polute the TCP/IP higher layer interfaces with link specific
stuff (this is about layer separation).
Another way to look at this : TCP/IP connections are mapped on
links through the IP routing table. Not all links may have a route
configured on them. A TCP connection may be migrated from one link to
another, or even "bonded" on two of them. I don't see how you could
get any way to map link information to TCP connections in any
meaningfull way.
For me, the events go sideway, directly into the management
plane (so, staying within layer 2, and not going to layer 3). Very
similar to the link layer configuration (ESSID, WEP) that is done
totally outside the TCP/IP stack (so, it's not a surprise that I
implemented those events in the link management channel). TCP/IP
doesn't have to know about those events, they are purely a link API
issue.
I would expect that the main use of those events would be for
user feedback ("your battery is flat and your connectivity shaky") and
other things that are totally unrelated to TCP/IP.
On top of that, the MobileIP manager or the AODV manager could
connect directly to the link interface to get those events and would
manipulate the routing table according to those (most OSes have well
defined APIs to manipulate routing table).
So, I guess that people interested in Link Triggers just need
to download their favorite Linux distribution, get a 802.11 card and
and start playing with it and making their own informed opinion ;-)
Have fun...
Jean
_______________________________________________
pilc mailing list
pilc@ietf.org
----- End forwarded message -----
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020928153021.6029.qmail>