Re: On Link Triggers (implementation)

Hi Jean,

Thank you for this very useful report...
Few comments...

> 2) Mechanisms
> -------------
> I fully agree with few people, the mechansisms to deliver
> those trigger are totally OS specific.

I believe your implementation and experiments were
for observing triggers on the wireless client side, rather
than the network side, right? Because if it is the network
side, then you'd see where these triggers are generated
(e.g., access point) and where they are consumed (e.g.,
access router) might not reside on the same node. 
Therefore OS-specific methods are not sufficient...

> 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.

Have you looked at:
http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-02.txt



> 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).

It really depends on where Mobile IP manager is implemented.
For Mobile IPv4, it's likely to be mostly a user-land daemon,
whereas for Mobile IPv6, kernel implementation is dominant.
For latter, clearly these triggers need to be passed to the IP
module.

Regards,

alper


_______________________________________________
pilc mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/