Subject: [mobile-ip] Link Triggers

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 27 Sep 2002 10:15:16 -0500

Hi,
  Jean Thourrilhes has posted this message on pilc ML, I am reposting it 
here as it might interest many in this ML.

>
> To: [email-masked]
> From: "Jean Tourrilhes" <[email-masked]> | This is Spam | Add 
> to Address Book
> 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
> [email-masked]
>

-- 
Behcet