Subject: [seamoby] An API issue

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 16 May 2001 14:22:24 -0500

Dear All:

I have a problem and was wondering if anyone else
has encountered this...

This may be the wrong place to take this issue Pat, if it
is, please redirect me..

Here is the jest of the problem. I have a wireless card
driver (it can be any type you can imagine.. GSM, 802.11
even blue-tooth...).

It gets a signal that an event has transpired
i.e. Association fell apart or came up, i.e. I can now reach
a AR or I can no longer reach an AR or maybe some other trigger
type event of interest. This is the ole Layer-2
trigger that everyone talks about....

Now HOW do I get it up to layer 3?

This seems like a real naive question I know... but when you
start digging in to at least most unixy stacks, you have 
a layer 2 driver servicing the card (or is it layer 1:>),
its interfaces to upper layers are:

A) ioctl... user requests/response model
B) packet arrival -> submit to ether_input()
C) packet sending -> output routine is called.

Now I can use A if you want to have the interested upper
layer poll every N interval and ask... hey what is your
current status? But this means that N becomes the granularity
of when you might want to handoff/do something. This could
be a real problem for real time services...

I can't use C.. after all this is output..

And B seems pointless as well.. there is NO packet defined
or protocol defined I can launch up to the layer above that
will resolve to the listner.

Ideally it would be nice to send a "Layer 2" Trigger message
in (B). One could even envision an "ether protocol id" that directs
the above layer to send it down a particular Layer 3 path where
a reader would get it... I have thought about doing this using
FreeBSD's routing sockets and allowing it to get this type
of input event... but its not standard...

It would be nice to have some sort of standard way to signal
upwards these Layer-2 triggers (if available). Has anyone
thought of this? I would be willing to write a draft on this
if folks thought it was a good idea... but it really has no
wire side protocol basis... of course neither does a lot of
the sockets mapping api's either :/ 

I would appreciate either re-direction or comments from you all
who may have thought of this..

Thanks

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

---

From: Marco Molteni <[email-masked]>
Date: Wed, 16 May 2001 22:41:47 +0200

On 2001-05-16, Randall R. Stewart wrote:

Hi Randall,

[..]

> Here is the jest of the problem. I have a wireless card driver (it
> can be any type you can imagine.. GSM, 802.11 even blue-tooth...).
>
> It gets a signal that an event has transpired i.e. Association fell
> apart or came up, i.e. I can now reach a AR or I can no longer reach
> an AR or maybe some other trigger type event of interest. This is
> the ole Layer-2 trigger that everyone talks about....
> 
> This seems like a real naive question I know... but when you start
> digging in to at least most unixy stacks, you have a layer 2 driver
> servicing the card (or is it layer 1:>), its interfaces to upper
> layers are:
> 

[..]

I have a suggestion for the kernel -> userland case: write a pseudo
device driver.

Usage scenarios:

1. synchronous, but not polling:
   you can select(2) or poll(2) a descriptor bound to the device, and have
   the device make the descriptor ready for reading when an event occurs.

2. asynchronous:
   have the pseudo device send a signal to the process who opened it when
   an event occurs.

in both scenarios then you can either read from it or issue an ioctl to
have further informations on the event.

Marco

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 17 May 2001 06:23:49 -0500

Marco:

It is not that I could not hack something together there
are several possiblities. And I don't think I would
approach it from the aspect of a pseudo driver since
I already have a driver. With most e-net type drivers you don't
read directly from... this could be added... but I was
just hoping (in vain I see from most of the email) that
we might all have a standard way to approach the
problem so in the end everyone's card(s) would work and
play nice together...

R

---

From: Jim Bound <[email-masked]>
Date: Thu, 17 May 2001 21:47:35 -0400 (EDT)

Randy,

This is out of scope for the IETF.  you and I both know a real OS kernel
programmer will use the inherent features available to them on their OS
net subsystem stack implementation so they get the best peformance
relative to their stacks main business.

For me for real paying customers and in a real product I would send it
from the driver to my Teclo/Wireless proprietary input queues that would
heed that packet prior to ipintrq from enet et al.  I would do that by
providing the L2 context its own thread (not same as ipintrq) and make
sure I could run it on at least 8 processors using the memory sharing
capabilities via SMP on my companys machines.

The last thing we need for seamoby type operations is a PF_ROUTE socket or
user space IOCTL listening to a device driver.  With everything else we
have to fix we learn from pilc wg we should not add yet more pain to low
bandwidth / high latency connections.

Someone should just do it in freebsd or netbsd and see what happens. But
yet another API from the IETF...not a good idea IMO.

/jim