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

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Wed, 3 Aug 2005 01:49:03 -0700

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Vakulenko
Sent: Wednesday, August 03, 2005 12:27 AM
To: Pat Calhoun (pacalhou)
Cc: Yuval Cohen; Tal Anker; [email-masked]
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:[email-masked]]
> > Sent: Tuesday, August 02, 2005 3:18 PM
> > To: Pat Calhoun (pacalhou)
> > Cc: Tal Anker; [email-masked]
> > 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: [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
> >
>_______________________________________________
>Capwap mailing list
>[email-masked]
>http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Michael Vakulenko <[email-masked]>
Date: Wed, 03 Aug 2005 12:21:52 +0300

Bob,

Pls see my comments below.

Thanks,

-- Michael V.
         www.WaveCompass.com

>variant supported by LWAPP.  In fact, that is what the taxonomy draft

I don't see there is a controversy here. I'll clarify what is the 
point of discussion: The question relates to the split-MAC operation. 
Current LWAPP draft has a limitation of tunneling of 802.11 frames to 
the AC. The suggestion is to allow tunneling of 802.3 frames in 
addition to 802.11. WTP will select tunneling type on command from 
the AC. In my opinion, support for 802.3 tunneling shall be mandatory 
with the option of 802.11 tunneling for the reasons listed in the 
previous email exchanges.

>have a hammer, doesn't mean that everything else in the world is a nail.

It is not ridiculous at all if we'll think about it little bit more. 
By tunneling 802.3 frames we can centralize Portal function of 802.11 
DS. This has great advantages in handing mobility of stations. This 
is where the hammer finds the nail....

>directly, since the frames and their information arrived whole and

Tremendous complication sounds like an overstatement here. Some 
vendors make choose to trade the need for correlation for simplicity, 
cost and efficiency in the data plane processing. In the end, vendor 
flexibility is one of the CAPWAP mandatory objectives. Airespace 
design, with all due respect (really), is not the only design possible.

Besides, I just don't get how forwarding of 802.11 frames helps you 
to provide RSSI to the AC. You know better than me that 802.11 frame 
format doesn't have RSSI field.

>Of course, this reduces the amount of information available to the AC,

You are assuming that the AC absolutely needs all this information. 
This assumption may not hold for other vendors, which may use other, 
possibly more efficient methods to achieve the same goals.