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

From: Michael Montemurro <[email-masked]>
Date: Wed, 3 Aug 2005 16:42:32 -0400

I would agree with this using 802.3 for local MAC and 802.xx for split MAC
would be a reasonable compromise to this issue.

Mike

Michael Montemurro
Director, Advanced Technology and Standards
Chantry Networks, A Siemens Company
1900 Minnesota Ct, Suite 125
Mississauga, ON, CANADA.
T: 905-363-6413
F: 905-567-9900
E: [email-masked]  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Pat Calhoun (pacalhou)
> Sent: August 3, 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Ʃ
> 
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Dan Harkins <[email-masked]>
Date: Thu, 04 Aug 2005 00:43:55 -0700

So are we saying that if the integration service is performed on the WTP
then you're "local MAC" regardless of any of the other non-real time
functions that may be done on the AC? I'm not sure I agree with that.

  By the way, if the 802.1x authenticator is on the AC then I think you
are by definition a split MAC. No?

  Dan.  

On Wed, 03 Aug 2005 16:42:32 EDT you wrote