Subject: RE: [Seamoby] LWAPP

From: "Paine, Richard H" <[email-masked]>
Date: Wed, 9 Apr 2003 14:51:57 -0700

Are you all aware that IEEE 802.11k is working to make the measurements in the 802.11 PHYs and MACs available for upper layers?  This includes per AP tables and per STA tables.  I think your  triggers could be determined from the signal strength and other measurements available through 802.11k.

Richard H. Paine
Success is getting what you want, happiness is liking what you get!
Work: 425-865-4921
Pager: 206-797-4580
Cell:  206-854-8199
IPPhone:  425-373-8964
Email:  [email-masked] 

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Tuesday, April 08, 2003 3:59 PM
To: Pat Calhoun
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Glen Zorn; [email-masked]
Subject: Re: [Seamoby] LWAPP

>>> No, it's does alot more than just configure APs. The information 
>>> provided in the protocol can provide many additional features, 
>>> include fast handoffs, creating a secure interface between the AP 
>>> and the AR, etc.
>> 
>> I don't see any fast handoffs information carried in the draft.
>> 
> A foobar on my part. There is a message between the AP and the AR that 
> is used to communicate a trigger. Used with the signal strength in the 
> message (which is already in the draft), it can be used by the AR to 
> determine a mobile's current point of attachment.
> 
> I put out the document rather hastily, but will follow up with another 
> version that includes this (and the formatting problems).

If you are talking about carrying L2 event notifications around, please see:

http://ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt

How does what you have in mind compare/relate to the above draft?

> 
>> I'm not sure
>> what exactly you mean by "secure interface", but based on my reading 
>> of the draft the only security is for protecting this protocol's 
>> packets between the AP and the AR. And this is not an additional 
>> feature but a requirement on the protocol.
> 
> Correct - that is the secure interface I mentioned. It is assumed that 
> the user will protect his/her own traffic... and that the AR will 
> enforce whatever policy it has defined. LWAPP was not intended to 
> replace end-to-end security, but securing that interface *is* a 
> requirement, not an additional feature. A malicious AP can do very 
> nasty things to an AR.
> 
>>> 
>>> Further, the market has made it pretty clear that they no longer 
>>> want smart APs that have to be managed individually. They want a 
>>> central point of control, with remote interfaces. But this is a 
>>> market issue, not a standards one.
>> 
>> This makes sense. But is there any difference between your proposed 
>> protocol and SNMP in this context?
> 
> Sure, let me explain.
> 
> What we've heard from our customers is that they are tired to managing 
> APs scattered throughout their networks (oh, and it's clear the 
> industry is moving in this direction, these are not just my own 
> ramblings). The issue SNMP in the AP is that it does require the 
> administrator to touch the device. People want a secure plug and play 
> solution. If SNMP is on the box, you must configure the community 
> string (and user in the case of v3), and this security relationship is 
> one that must be administered over the course of the device's 
> lifetime. The market is pretty clear in the fact that it wants an AP 
> that can auto-discover ARs and establish a security relationship w/o 
> any administrator involvement. The draft's use of certificates 
> provides this feature, but I agree that a shared secret mechanism 
> should probably  be defined as well.

If I'm understanding this right, the problem is that SNMP does not know how to use certificates for authentication.... I don't know how hard it is to solve this if it is needed as you described....

alper

> 
> PatC
> 
> _______________________________________________
> Seamoby mailing list
> [email-masked] https://www1.ietf.org/mailman/listinfo/seamoby
> 

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Raymond J. Jayabal" <[email-masked]>
Date: Thu, 10 Apr 2003 10:15:04 +0800

Hi,

Pardon me for borrowing a bit of your time.

I'm a researcher working on signal strength based anticipative L3
handover over over 802.11. Will 802.11k allow the mobile node to report
signal strength measurements for the serving and neighbouring access
points to the serving AP, and also allow L3 to somehow get these
reports?

- Ray

------------------------------------------------------------------------
Raymond J. Jayabal                 | I2R, A-STAR
[email-masked]         | 20 Science Park Rd #02-34/37
Tel: +65 6870 9330                 | Singapore 117674
------------------------------------------------------------------------

----- Original Message -----

Subject: RE: [Seamoby] LWAPP

> Are you all aware that IEEE 802.11k is working to make the
measurements in the 802.11 PHYs and MACs available for upper layers?
This includes per AP tables and per STA tables.  I think your  triggers
could be determined from the signal strength and other measurements
available through 802.11k.
> Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Glen Zorn; [email-masked]
> If I'm understanding this right, the problem is that SNMP does not
know how to use certificates for authentication.... I don't know how
hard it is to solve this if it is needed as you described....

---

From: Pat Calhoun <[email-masked]>
Date: 10 Apr 2003 08:11:40 -0700

> Are you all aware that IEEE 802.11k is working to make the measurements in the 802.11 PHYs and MACs available for upper layers?  This includes per AP tables and per STA tables.  I think your  trigg…

Correct, and since LWAPP provides signal strength to the AR, it would be a great container to send the 11k info to the controller.

PatC