Subject: RE: [Capwap] comment about LWAPP and other wireless technologies

From: "Yuval Cohen" <[email-masked]>
Date: Wed, 3 Aug 2005 01:18:27 +0300

Pat,
While the control path is usually implemented in CPU, the data path in some cases is realized in silicon. Processing 802.11 frames may add to complexity and cost.

I agree that in some cases, there is a need for the WTP to send the 802.11 frame, as in the case of centralized crypto (although that may conflict with HCCA) but for those implementations not requiring that and in particular local AP case, there is no real need for 802.11 frame reaching the AC.
The extra info within the 802.11 frame can be processed within the WTP and provided to the AC if needed via the control plane, possibly after some digestion. 
Using 802.3 frames only, will keep the implementation simple and will enable a large install base of existing switches to become AC with just software upgrade. This will aid wide adoption of LDAP.

My recommendation is that LWAPP will not limit the frame format to 802.11 only but rather allow two formats, either 802.11 or 802.3. 

Yuval

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pat Calhoun (pacalhou)
Sent: Wednesday, August 03, 2005 12:16 AM
To: Tal Anker; [email-masked]
Subject: RE: [Capwap] comment about LWAPP and other wireless technologies

Tal,

Thanks for the e-mail.

I believe that I understand your point, but I would argue that the AC
will have to be modified to support a new technology, and that upgrading
the code in the data path is really no more difficult than the control
path. If an implementation exists that does not allow for upgrade, then
it is limiting its market.

I would argue that include "technology specific" information piggy
backed within the LWAPP data frame would be hard to achieve, because we
cannot predict what this information would end up being. For instance,
802.11 has the concept of a BSSID, while 802.16 has something different
(and has additional information). So how would you map 802.11 QoS field
into a field that may not match with 802.16s?

If one were to need to extend the piggy backed header, then this would
require changes to the data path anyhow. Further, certain features will
require changes to the data path, for instance the introduction of
802.11i centralized encryption requires that the data path perform
AES-CCMP, and 802.11e requires specific quality of service queuing and
policing.

So while I understand the point raised, I firmly believe that
transporting the native frame provides the AC with all of the
information for the specific technology, and allows it to provide
differentiated services based on the information present - vs. limiting
it to what generic information would be in this piggy backed header.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tal Anker
> Sent: Tuesday, August 02, 2005 7:47 AM
> To: [email-masked]
> Subject: [Capwap] comment about LWAPP and other wireless technologies
> 
> Resending this (it seems the first attempt fails... 
> appologies if you receive duplicate copies...).
> 
> Hi,
> while going over the LWAPP draft and on the objecives of 
> CAPWAP there seems to be a CAPWAP objective that may not be 
> fully achieved with the current LWAPP spec.
> The LWAPP specification requires that the 802.11 frames would 
> be encapsulated by the WTP and sent to the AC for processing. 
> The benefit from doing this is having the original info 
> carried in the .11 frame available to the AC.
> However, this requires the AC to process the native 802.11 
> frames; an operation that will probably be done in some HW 
> component. My concern is that one of the CAPWAP objectives 
> was to be applicable not only to 802.11 but for various 
> wireless technologies. As a result the LWAPP should also be 
> applicable no only for 802.11... (as it indeed states in the 
> beginning of the LWAPP draft). However mandating that the 
> wireless media frames would be sent to the AC in their 
> original format would make this objective harder to 
> achieve... When a new wireless media type would be 
> introduced, the AC would have to be somehow adapted to 
> process the data frames (not only the control frames that can 
> obviously be processed in the AC cpu...).
> This means either a HW change (or if the AC is using NP then 
> an NP SW upgrade).
> What seems reasonable to do is to add the OPTION for sending 
> the data frames to the AC using the media type tha tthe WTP 
> is connected to the AC with. Meaning - to convert the frame 
> in the WTP and to send it to the AC for instance using 802.3 
> ethernet frames... This way when a new wireless technology is 
> inroduced to the AC all that needs to be done is updating the 
> SW of the AC.
> 
> As for loosing the specific media information that was in the 
> 802.11 header - this info can be collected by the WTP and be 
> sent to the AC using LWAPP protocol messages...
> 
> Supporting both the current LWAPP suggestion (sending the 
> original 802.11 frames to the AC) AND the option to convert 
> to the AC media type will allow LWAPP to comply to the 
> "future wireless technologies" objective...
> 
> - Tal
> 
> =====================================================================
> Tal Anker, PhD.
> DANSS - Distributed Algorithms, Networking and Secure Systems Group.
> The School of Engineering and Computer Science, The hebrew 
> University of Jerusalem, Israel.
> 
> 
> 
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
> 
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap
jœ¦f¢–)à–+-	ªpj—ëjÇ(�ç(šm§ÿæj)_«¢wœ¢oæj)fjåŠËb�ú?qªpj

---

From: Dan Harkins <[email-masked]>
Date: Wed, 03 Aug 2005 03:02:04 -0700

Hi Yuval,

  I'd like to note that SLAPP allows either 802.3 or 802.11 frames to
be GRE encapsulated and sent to the AC. This is a very important
feature.

  Dan.

On Wed, 03 Aug 2005 01:18:27 +0300 you wrote
> Pat,
> While the control path is usually implemented in CPU, the data path in some c
>ases is realized in silicon. Processing 802.11 frames may add to complexity an
>d cost.
> 
> I agree that in some cases, there is a need for the WTP to send the 802.11 fr
>ame, as in the case of centralized crypto (although that may conflict with HCC
>A) but for those implementations not requiring that and in particular local AP
> case, there is no real need for 802.11 frame reaching the AC.
> The extra info within the 802.11 frame can be processed within the WTP and pr
>ovided to the AC if needed via the control plane, possibly after some digestio
>n. 
> Using 802.3 frames only, will keep the implementation simple and will enable 
>a large install base of existing switches to become AC with just software upgr
>ade. This will aid wide adoption of LDAP.
> 
> 
> My recommendation is that LWAPP will not limit the frame format to 802.11 onl
>y but rather allow two formats, either 802.11 or 802.3. 
> 
> Yuval
>  
> 
> 
> ������������������������������������j��f��)��+-	�pj�߭��w�r���������_߭��w�r���������+-�w��Ʃ
>