Capwap Mailing List: RE: comment about LWAPP and other wireless technologies

[Sadot, Emek (Emek) (esadot]

As terminating 802.11 at the WTP, converting to 802.3 and sending to the AC may 
be a good idea, I would argue against specifying this embodiment as mandatory. 
It border impossible to ensure that WTP to AC communication will always travel 
over 802.3 network. Although I concur it's the common practice in LAN 
environment, I would challenge its applicability to the WiMAX, or for that 
matter to other wireless technologies.

Regards,
Emek

-----Original Message-----
From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] frascone.com] On 
Behalf Of Yuval Cohen
Sent: Wednesday, August 03, 2005 5:55 AM
To: Bob O'Hara (boohara); capwap [at] frascone.com
Subject: RE: [Capwap] comment about LWAPP and other wireless technologies

Bob,
the discussion is not only about local MAC but also about split MAC. The local 
MAC was given just as an example.
For reasons provided before, I see also a lot of sense in using 802.3 frames 
also in the split MAC case, where you do the distribution function (based on 
802.3 frame switching) within the AC Since in any case you need to add the 
802.11 specific info (like RSSI), I'd rather see it within the LWAPP tunnel 
header so I can choose if to take it from there or not and keep the frame 
802.3. This will give the most flexibility for those implementations that need 
the extra info and for those looking into simple implementations not requiring 
processing the extra info or allowing processing in the WTP 

I would like to hear more opinions on the WG mailing list as to how important 
it is to support this also in split MAC case

Yuval





-----Original Message-----
From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] frascone.com] On 
Behalf Of Bob O'Hara (boohara)
Sent: Wednesday, August 03, 2005 11:49 AM
To: capwap [at] frascone.com
Subject: RE: [Capwap] comment about LWAPP and other wireless technologies

I guess I fail to see what this controversy is all about.  If you want to 
forward 802.3 frames from the WTP, you are using the local MAC variant 
supported by LWAPP.  In fact, that is what the taxonomy draft specifies.  

If all you have in your AC is Ethernet switch silicon on the data path, this is 
the only reasonable implementation.  To say that another option is necessary to 
support conversion of 802.11 frames to 802.3 frames in the WTP in split MAC 
mode, separate the 802.11-specific information and forward the 802.3 frames and 
separated 802.11 information about those forwarded 802.3 frames in LWAPP 
packets is ridiculous.  Just because you have a hammer, doesn't mean that 
everything else in the world is a nail.

It seems that this is a tremendous complication to the AC, which now needs to 
correlate this separated information.  This correlation operation was not 
necessary when the 802.11 frames were forwarded directly, since the frames and 
their information arrived whole and together. 

In order to reduce the computing load on the AC to correlate the separated 
information, the WTP could send only summarized information.
Of course, this reduces the amount of information available to the AC, without 
justification.

 -Bob
 
-----Original Message-----
From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] frascone.com] On 
Behalf Of Michael Vakulenko
Sent: Wednesday, August 03, 2005 12:27 AM
To: Pat Calhoun (pacalhou)
Cc: Yuval Cohen; Tal Anker; capwap [at] frascone.com
Subject: RE: [Capwap] comment about LWAPP and other wireless technologies

Pat,

Your question is independent of whether CAPWAP tunnels 802.3 or
802.11 frame. Signal strength field does not present in 802.11 frame headers. 
Having tunnel 802.11 frames doesn't solve the problem.

Thanks,

-- Michael V.

At 08:46 AM 8/3/2005, Pat Calhoun \(pacalhou\) wrote:
>Yuval,
>
>I'd like to comment on your point about having the WTP process the 
>information, and provide a digested version of the information. How 
>would you propose that the WTP represent the changes in signal strength 
>(which occur in real time) to the AC - and how frequent would you 
>propose these updates be made? Would this be a packet that hits the 
>control processor, because if so, then I have some serious scaling 
>concerns.
>
>That said, I think that in the end we need the evaluation team to make
a
>recommendation on a protocol, and then let the WG decide. If the WG 
>decides that two separate protocol formats would be better than one, 
>then we can go down that path (and make sure that we make one mandatory 
>to implement).
>
>Pat Calhoun
>CTO, Wireless Networking Business Unit
>Cisco Systems
>
>
>
> > -----Original Message-----
> > From: Yuval Cohen [mailto:YuvalC [at] marvell.com]
> > Sent: Tuesday, August 02, 2005 3:18 PM
> > To: Pat Calhoun (pacalhou)
> > Cc: Tal Anker; capwap [at] frascone.com
> > Subject: RE: [Capwap] comment about LWAPP and other wireless 
> > technologies
> >
> > 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: capwap-admin [at] frascone.com
> > [mailto:capwap-admin [at] frascone.com] On Behalf Of Pat Calhoun
(pacalhou)
> > Sent: Wednesday, August 03, 2005 12:16 AM
> > To: Tal Anker; capwap [at] frascone.com
> > 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: capwap-admin [at] frascone.com
> > > [mailto:capwap-admin [at] frascone.com] On Behalf Of Tal Anker
> > > Sent: Tuesday, August 02, 2005 7:47 AM
> > > To: capwap [at] frascone.com
> > > 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
> > > Capwap [at] frascone.com
> > > http://mail.frascone.com/mailman/listinfo/capwap
> > >
> > _______________________________________________
> > Capwap mailing list
> > Capwap [at] frascone.com
> > http://mail.frascone.com/mailman/listinfo/capwap
> >
>_______________________________________________
>Capwap mailing list
>Capwap [at] frascone.com
>http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
Capwap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
Capwap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/capwap
        pjXX&_whm~rr+-wƩ