Subject: RE: [seamoby] An API issue

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 17 May 2001 15:21:29 -0400

> -----Original Message-----
> From: Randall R. Stewart [mailto:[email-masked]]
> Sent: Thursday, May 17, 2001 11:01 AM
> To: kempf
> Cc: [email-masked]
> Subject: Re: [seamoby] An API issue
> 
> 
> kempf wrote:
> > 
> > Randy,
> > 

> I think a more elegant and general approach would be to
> design an new socket type. Add a new ether type and 
> design general purpose data structures that could
> be passed up from the driver(s). Then you would
> end with a very generic solution that can be blocked/selected
> for read blocking or whatever...
> 
> Mores to the point you would have a standard data
> interface for Layer-2 triggers... 

I not sure what you were asking.  I agree, a API for layer-2 Triggers is
definitely something that needs to be worked on.

- Kulwinder.

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

---

From: "Hesham Soliman \(ERA\)" <[email-masked]>
Date: Sat, 19 May 2001 01:19:32 +0200

Hello Randall, 

I (and a couple of my colleagues) have encountered
exactly this problem and analysis. I fully agree with
your conclusions. We sort of came to the same conclusion. 

This seems relevant to the AP discovery work being 
done here. 

Hesham

> From:	Randall R. Stewart [SMTP:[email-masked]]
> Sent:	Thursday, 17 May 2001 5:22
> To:	[email-masked]
> Subject:	[seamoby] An API issue
> 
> 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