| Re: comment about LWAPP and other wireless technologies | <– Date –> <– Thread –> |
From: Dan Harkins (dharkins trpz.com)
|
|
| Date: Thu, 4 Aug 2005 03:54:36 -0400 (EDT) | |
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 > 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: michael.montemurro [at] siemens.com > > > -----Original Message----- > > From: capwap-admin [at] frascone.com > > [mailto:capwap-admin [at] frascone.com] On Behalf Of Pat Calhoun (pacalhou) > > Sent: August 3, 2005 9:57 AM > > To: Nehru Bhandaru; Yuval Cohen; Bob O'Hara (boohara); > > capwap [at] frascone.com > > 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: capwap-admin [at] frascone.com > > > [mailto:capwap-admin [at] frascone.com] On Behalf Of Nehru Bhandaru > > > Sent: Wednesday, August 03, 2005 5:39 AM > > > To: Yuval Cohen; Bob O'Hara (boohara); capwap [at] frascone.com > > > 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: 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Ʃ > > > j~rr > > > > > pjXX&_ whm~rr+-wƩ > > > _______________________________________________ > Capwap mailing list > Capwap [at] frascone.com > http://mail.frascone.com/mailman/listinfo/capwap
- RE: comment about LWAPP and other wireless technologies, (continued)
- RE: comment about LWAPP and other wireless technologies Nehru Bhandaru, August 3 2005
- RE: comment about LWAPP and other wireless technologies Pat Calhoun (pacalhou), August 3 2005
- RE: comment about LWAPP and other wireless technologies Nehru Bhandaru, August 3 2005
-
RE: comment about LWAPP and other wireless technologies Michael Montemurro, August 3 2005
- Re: comment about LWAPP and other wireless technologies Dan Harkins, August 4 2005
- RE: comment about LWAPP and other wireless technologies Yuval Cohen, August 3 2005
- RE: comment about LWAPP and other wireless technologies Sadot, Emek (Emek), August 4 2005
- RE: comment about LWAPP and other wireless technologies Sadot, Emek (Emek), August 4 2005
- RE: comment about LWAPP and other wireless technologies Pat Calhoun (pacalhou), August 8 2005
Results generated by Tiger Technologies using MHonArc.