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

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 5 Aug 2005 02:11:57 -0400

I respectfully disagree with the assumption that Split MAC is define as *all* AP functions in the AC, and in particular the DS. This issue was exhausted in the list. If my memory server me right the key arguments in favor of offload the DS to the WTP were:
- CAPWAP is a control protocol, has nothing to do with data flow
- Avoid hammering the AC with data traffic
- Shortest path for data packets

Regards,
Emek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pat Calhoun (pacalhou)
Sent: Wednesday, August 03, 2005 9:57 AM
To: Nehru Bhandaru; Yuval Cohen; Bob O'Hara (boohara); [email-masked]
Subject: RE: [Capwap] comment about LWAPP and other wireless technologies

So this would be an argument for local bridging and tunneling of 802.3 frames in local mode. I think that would be a good compromise. I believe that changing the basic fundamentals of Split MAC, which means *all* AP functions are performed in the AC (possibly including encryption), would be a mistake.

The taxonomy recommendation already recommends that Local MAC be the "mandatory" mode, but if the WG agrees, we could make changes to allow for tunneling of traffic in an 802.3 mode.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Nehru Bhandaru
> Sent: Wednesday, August 03, 2005 5:39 AM
> To: Yuval Cohen; Bob O'Hara (boohara); [email-masked]
> Subject: RE: [Capwap] comment about LWAPP and other wireless 
> technologies
> 
> 
> All,
> 
> IMHO supporting the case where 802.11 <-> 802.3 conversion is done at 
> the WTP and 802.3 is transported to AC is important to leverage 
> existing silicon in the data path at the AC. This can be accomplished 
> in many ways in CAPWAP - one option that seems to be under debate is 
> to consider this as a mode of Split MAC.
> 
> Another, something I like better and not very complicated, is to 
> consider this an Local MAC option where the integration/portal 
> function of 802.11 AP is at the AC. With this model, LWAPP control 
> protocol (in the Local MAC case) could negotiate the encapsulation for 
> the data path to the portal. This could be GRE, LWAPP(L2/L3) or 
> whatever - with inner payload of 802.3. RSSI/SNR/etc values can be 
> obtained from the encapsulation header...
> 
> Split MAC could carry 802.11 only in the data path.
> 
> - Nehru
> 
>     -----Original Message-----
>     From: [email-masked]
> [mailto:[email-masked]] On
>     Behalf Of Yuval Cohen
>     Sent: Wednesday, August 03, 2005 5:55 AM
>     To: Bob O'Hara (boohara); [email-masked]
>     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: [email-masked]
> [mailto:[email-masked]] On
>     Behalf Of Bob O'Hara (boohara)
>     Sent: Wednesday, August 03, 2005 11:49 AM
>     To: [email-masked]
>     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: [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
>     	pjXX&_whm~rr+-wƩ
> 	j~rr
> 
	pjXX&_whm~rr+-wƩ

j��f��)��+-	�pj��j�(��(�m���j)_���w��o�j)fj��b��?q�pj